本帖最后由 sailyang 于 2020-12-1 14:02 编辑
出现这种现象通常会在 MySQL 的错误日志里下面的提示:
mysqld got signal 11
我们使用 perror 查看一下 11 错误的原因:
root@scutech:~# perror 11
OS error code 11: Resource temporarily unavailable
MySQL error code MY-000011: Can't unlock file (OS errno %d - %s)
最常见的是系统内存不足,由于系统连接数的增加和每个连接对内存的占用增加,造成 MySQL 申请新的内存失败而 crash,此时错误日志里面通常有类似下面的记录:10:55:07 UTC - 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. Attempting to collect some information that could help diagnose the problem. As this is a crash and something is definitely wrong, the information collection process might fail. Please help us make Percona Server better by reporting any
key_buffer_size=16777216 read_buffer_size=8388608 max_used_connections=95 max_threads=50001 thread_count=31 connection_count=28 It is possible that mysqld could use up to key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 819273023 K bytes of memory Hope that's ok; if not, decrease some variables in the equation.
此段的记录里面列出了内存占用的计算方法,但需要注意这个公式里面没有把内存占用的大户,Innodb 的 buffer pool 计算进来,大家可以用这个公式加上 buffer pool 计算自己的内存占用,然后根据自己的实际情况对各个参数进行调整,如果连接数过多,可以通过修改 max_connections 对最大连接数进行限制。
除了内存不足造成 MySQL 申请系统资源失败外,另一个常见的现象是磁盘问题,例如磁盘空间满了,磁盘上的文件 corrupt 都会造成 MySQL crash。此时需要定位 crash 的根本原因有下面几种方法:
仔细阅读 MySQL 的错误日志,这个日志里面的一些程序调试信息看起来很让人困惑,但静下心来仔细看,很多时候会找到线索;
打开 general query log ,找到最后一个 sql 访问的表或索引,检查这个表或索引,如果有问题就重建,通常可以解决问题。
开启 core dump,使用 gdb 分析 core file;
使用 strace 跟踪 mysqld 进程的系统调用;
使用 CMake 的选项 -DWITH_DEBUG=1 重新编译 mysqld,然后运行重新编译后的 mysqld,查看 trace 文件。 |