A very strange behaviour with MySQL (InnoDB) and feoktistov Kernel on Gentoo [message #42211] |
Fri, 18 March 2011 14:57 |
manuuu
Messages: 2 Registered: March 2011
|
Junior Member |
|
|
Hello everybody,
I have a very strange behaviour on one of my VPS with that kernel (I didn't tried the previous one because of an NFS issue that completely freeze my system).
When I create a database with InnodB the server crashes, same when I execute mysqltunner and I have innodb tables :
110318 20:20:30 InnoDB: Assertion failure in thread 140308909500176 in file fil/fil0fil.c line 635
InnoDB: Failing assertion: ret
InnoDB: We intentionally generate a memory trap.
InnoDB: Submit a detailed bug report to http../bugs.mysql.com.
InnoDB: If you get repeated assertion failures or crashes, even
InnoDB: immediately after the mysqld startup, there may be
InnoDB: corruption in the InnoDB tablespace. Please refer to
InnoDB: http../dev.mysql.com/doc/refman/5.1/en/forcing-recovery.html
InnoDB: about forcing recovery.
110318 20:20:30 - mysqld got signal 6 ;
This could be because you hit a bug. It is also possible that this binary
or one of the libraries it was linked against is corrupt, improperly built,
or misconfigured. This error can also be caused by malfunctioning hardware.
We will try our best to scrape up some info that will hopefully help diagnose
the problem, but since we have already crashed, something is definitely wrong
and this may fail.
key_buffer_size=16777216
read_buffer_size=262144
max_used_connections=4
max_threads=151
threads_connected=2
It is possible that mysqld could use up to
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 133904 K
bytes of memory
Hope that's ok; if not, decrease some variables in the equation.
thd: 0x14605b0
Attempting backtrace. You can use the following information to find out
where mysqld died. If you see no messages after this, something went
terribly wrong...
stack_bottom = 0x7f9c36b59e88 thread_stack 0x40000
Let see the resources after the crash :
cat /proc/bc/230/resources
kmemsize 3127245 6561530 23372700 147901640000000 0
lockedpages 0 0 256 256 0
privvmpages 24021 71909 384000 384000 0
shmpages 1 657 2150400 21504000 0
numproc 28 56 2400 3400000000 0
physpages 3103 26819 0 9223372036854775807 0
vmguarpages 0 0 33792 9223372036854775807 0
oomguarpages 3103 26819 261120 9223372036854775807 0
numtcpsock 6 13 360 360 0
numflock 3 188 188 206 2
numpty 0 2 16 16 0
numsiginfo 0 6 256 256 0
tcpsndbuf 104640 1502152 1720320 2703360 0
tcprcvbuf 98304 216096 1720320 2703360 0
othersockbuf 136408 156392 1126080 2097152 0
dgramrcvbuf 0 4360 262144 262144 0
numothersock 105 118 360 360 0
dcachesize 191310 673923 3409920 3624960 0
numfile 590 1507 9312 9312 0
numiptent 27 27 128 128 0
swappages 0 0 223727 283727 0
I tried many MySQL configurations options, as well as different MySQL versions... It happens for a CentOS guest and a Gentoo guest. I checked /proc/user_beancounters and I have sometimes very strange values (fails on tcpsndbuf or numflock by 1 or 3).
I had some problems with Apache (I don't remember the messages but APC was not working for PHP And I had something like "couldn't fork")as well on other VPS and I had to increase the RAM to 2GB even it never spend more than 600Mb.
I have something strange with the memory management.
Thanks for you help
|
|
|
Re: A very strange behaviour with MySQL (InnoDB) and feoktistov Kernel on Gentoo [message #42228 is a reply to message #42211] |
Mon, 21 March 2011 11:10 |
manuuu
Messages: 2 Registered: March 2011
|
Junior Member |
|
|
Hi,
Some news, i have installed a fresh new mysql server and I get that after trying to create an Innodb table (it doesn't happen for all and I have reseted my.cnf and /var/lib/mysql to the default) :
InnoDB: The file already exists though the corresponding table did not
InnoDB: exist in the InnoDB data dictionary. Have you moved InnoDB
InnoDB: .ibd files around without using the SQL commands
InnoDB: DISCARD TABLESPACE and IMPORT TABLESPACE, or did
InnoDB: mysqld crash in the middle of CREATE TABLE? You can
InnoDB: resolve the problem by removing the file './sqldms/active_sessions.ibd'
|
|
|