这里我们的场景是mysql client已经无法登陆,无法执行sql。
基本思路是打出堆栈来分析
此时首先怀疑mysql内部发生了死锁
1. 使用pstack打出堆栈,会有一定性能影响
yum install gdb pstack mysql_pid > /tmp/pstack.out
也可以用gdb
gdb -batch -ex "thread apply all bt" -p mysql_pid > /tmp/gdb.log
堆栈可能比较多,需要耐心一点点排查,找出死锁的调用路径
2. 使用strace打出一段时间内的系统调用信息,会有一定性能影响
strace -o /tmp/strace_output.txt -T -tt -f -e trace=all -p {mysql_pid}
可以作为额外信息,辅助堆栈的排查
如果pstack或gdb也无法进入,那可能mysql已经不响应信号了
只能从操作系统提供的proc文件收集一些信息
cat /proc/mysql_pid/status
注意,status里除了进程状态之外,也有信号处理相关的信息Sig*
cat /proc/mysql_pid/task/*/stack
cat /proc/mysql_pid/syscall
cat /proc/mysql_pid/stack
当前的系统调用信息,比如是不是某个系统调用一直没有返回
ps -p{mysql_pid} -ocmd,stat,wchan
如果proc文件显示进程处于Running状态,没有夯在任何系统调用上
我目前能找到的方法就是打coredump,会杀死进程,但是能留下堆栈
prlimit --p $(mysql pid) --core=unlimited
先调整core limit,保证coredump文件能正常生成(linux 内核版本 2.6.36 以后才能使用prlimit)
kill -SIGSYS mysql_pid
linux有很多默认行为是打coredump的信号,但是有些信号被mysql捕获自己做了处理,比如SIGABRT,所以这里我们用SIGSYS 参考:http://man7.org/linux/man-pages/man7/signal.7.html
如果以上方法都没有成功收集到堆栈
那可能是操作系统层面的问题(或许可以从redhat bug文档中找类似问题),或者是硬件问题,不简单是mysql bug导致的死锁
来源:oschina
链接:https://my.oschina.net/u/3211934/blog/3190544