Hi!
>>>>> "Peter" == Peter Zaitsev <pz@stripped> writes:
Peter> Having troble with mysql 3.23.12c running on LINUX 2.2.14 (Suse 6.3) on PIII
Peter> SMP compiled as static with GCC 2.95.2
Peter> I never had this problem with 3.23.10 then have runned it for several weeks,
Peter> there it has some other bugs which does not allow me to switch back to it.
Peter> The problem is - sometimes (I got this problems twice in 48 hours) In a
Peter> moment I get MYSQLD hanged on disk writes or so on - some queries to heap
Peter> tables pass but others does not. The top shows one of processes of MYSQLD
Peter> trying to hog all cpu (probably thread manager ?), all other processes of
Peter> mysqld are locked running in rt_sigsuspend. DISKIO is on zero level. I can't
Peter> sutdown mysqld - nor mysqladmin shutdown nor kill helps - mysqld momentaly
Peter> stops open the queries but does not shutdown. Kill -9 helped of couse.
Peter> Here is some information I can provide to help to find more sertain bug
Peter> location:
<cut>
The big number of threads is probably because some thread got stuck.
To be able to fix this I would either need a backtrace of all threads
when this happens or some simple test program to be able to simulate
this.
The only bug I know if in 3.23.12 is that you should not drop a table
that you have a LOCK TABLES on, if you are locking more than one
table, but I don't think this is the one you got :(
This looks like some mutex gets hold without getting freed, properly.
You may be able to find this by recompiling MySQL with
CFLAGS=-DSAFE_MUTEX CXXFLAGS=-DSAFE_MUTEX
This will print to the .err file if MySQL detects any wrong usage of
some mutex.
Can you also check if you have some thread in a 'zombie' state
(In top these is shown as [mysqld]) This means that a thread has
crashed and this could explain the problem with stuck threads. In
this case the problem is a bit simpler as we only need to find out why
one thread is dying...
Regards,
Monty
