OpenVZ Forum


Home » General » Support » A very strange behaviour with MySQL (InnoDB) and feoktistov Kernel on Gentoo (Crashes and file unreadable)
A very strange behaviour with MySQL (InnoDB) and feoktistov Kernel on Gentoo [message #42211] Fri, 18 March 2011 14:57 Go to previous message
manuuu is currently offline  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
 
Read Message
Read Message
Previous Topic: [IPVS] try to install ipvs into VE
Next Topic: OpenVZ Containers over ZFS
Goto Forum:
  


Current Time: Wed Jul 31 01:19:54 GMT 2024

Total time taken to generate the page: 0.02900 seconds