MySQL thread deadlock, even after r195403 libthr fix

Nick Esborn nick at
Mon Jul 13 20:20:59 UTC 2009


I am working with a 16-core Opteron server which runs five different  
MySQL 5.0 processes, each with different data sets on MyISAM tables,  
in jails.  It ran flawlessly for about six months under 7.0.

After upgrading from 7.0 to 7.2, one of the MySQL processes has begun  
exhibiting a serious problem.  Within anywhere from several hours to a  
day or two after starting the process, a query thread will lock up.   
Output from procstat -k for such a thread:

3896 100795 mysqld           -                mi_switch  
sleepq_catch_signals sleepq_wait_sig _sleep do_rw_rdlock  
__umtx_op_rw_rdlock syscall Xfast_syscall

Once this thread locks up, replication grinds to a halt, as the thread  
holds read locks.  To unwedge the situation, I have to kill -9 the  
mysqld process, myisamchk the tables, and start the process back up  

7.2-RELEASE-p2 did not resolve the problem.   Late last week I  
upgraded to 8.0-BETA1 with the r195403 libthr fix, but that also  
failed to resolve the problem.  Mind you, in every other way, 8.0 is  
amazing on this 16-core server.

I had initially filed a bug report here:

This was before the 16-core upgrade, and before trying 8.0.

Subsequently, though, a conversation with Jeff Roberson helped me  
realize that it's more likely a kernel issue than a MySQL one.

I hope this deadlock can be resolved.  We really need 8.0's  
performance on this class of server.



nick at - all messages cryptographically signed

-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 194 bytes
Desc: This is a digitally signed message part
Url :

More information about the freebsd-current mailing list