Dotaz: Zaseknutí MySQL z ničeho nic

[arthurmax]

Zdravím všechny administrátory,
mám tento problém. Běží mi MySQL 4.0 na serveru (MDK 10.0 / 2.4 SMP) a běželo to tak 4 mesice bez problemu a najednou poslednich par tydnu se MySQL z niceho nic zasekne.

V logu nic neni, ona se zasekne tak, ze porad bezi, dostanu se do konzole a dostanu se i pres PHPMyAdmin do ni a vidim process list a tam je nekolik set dotazu, ktere cekaji na vyrizeni, ale at se snazim sebevic, tak to nejde rozchodit. Ani MySQL nejde restartovat, pouze kill vlakna a spusteni znovu a pak vse opet jde tak jak ma jit. LOAD je kolem 1.

Jadro taky nic nehlasi, puvodne jsem si myslel, ze to je kvuli flush-hosts, ale tam jsem dal limit na 1 MLD chybnych pripojeni, takze tim to uz neni. Zkousel jsem v PHP jak connect tak pconnect a porad to dela. Muze to kousnou nejaky SQL dotaz? Neda se tomu nejak zamezit? Tedka nevim jestli mysql umi neco na timeout zpracovani sql dotazu? Diky vsem za nakopnuti.

Jedine co se deje v logu je to, kde dojde k samovolnemu restartu mysql, nevite jak to odstranit?

050801 21:11:05  mysqld restarted
Warning: Ignoring user change to 'mysql' because the user was set to 'mysql' earlier on the command line
050801 21:11:05  InnoDB: Started
/usr/local/libexec/mysqld: ready for connections.
Version: '4.0.18-log'  socket: '/var/lib/mysql/mysql.sock'  port: 3306
mysqld got signal 11;
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=268435456
read_buffer_size=1044480
max_used_connections=504
max_connections=1000
threads_connected=7
It is possible that mysqld could use up to 
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_connections = 2306136 K
bytes of memory
Hope that's ok; if not, decrease some variables in the equation.

thd=0x57555c48
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...
Cannot determine thread, fp=0x59a4386c, backtrace may not be correct.
Stack range sanity check OK, backtrace follows:
0x810b6fc
0x4009d218
0xffffffff
0x817ed54
0x81767ca
0x81430b7
0x8142d16
0x813a658
0x81387a8
0x811cce6
0x811e8d4
0x81190a9
0x8118591
0x8117cfa
0x400967d3
0x40278b4a
New value of fp=(nil) failed sanity check, terminating stack trace!
Please read http://www.mysql.com/doc/en/Using_stack_trace.html and follow instructions on how to resolve the stack trace. Resolved
stack trace is much more helpful in diagnosing the problem, so please do 
resolve it
Trying to get some variables.
Some pointers may be invalid and cause the dump to abort...
thd->query at 0x5cb0d140  is invalid pointer
thd->thread_id=1308208
The manual page at http://www.mysql.com/doc/en/Crashing.html contains
information that should help you find out what is causing the crash.

Na otázku zatím nikdo bohužel neodpověděl.