记一次服务器 MySQL 服务崩坏经历…


今天打开我博客突然再次出现了 database error 的信息……显然 MySQL 服务再次崩坏了。上次崩坏已经尝试过跳大系统栈的方法,这次的崩坏仿佛是另一种错误(吐血……)。

调整系统栈大小

之前服务器的崩坏也是 MySQL 服务停止运行,打开 /var/log/mysqld.log,发现下面一行错误信息:

InnoDB: Error: pthread_create returned 11

去 Google 了一番,看到大部分人都说大概是系统栈大小的问题。(这里有个坑,网上很多人说的执行 ulimit -s unlimited 命令是没有用的!因为 ulimit 这个命令只在当前 shell 会话有效,也就是说当你关闭 SSH 连接的终端,它就会改回去……(不信可以试试))

最后的解决办法是:修改 /etc/security/limits.conf 这个文件。在里面(根据文件内的指导)加上:

*                soft    stack           28000
*                hard    stack           32768

这样就能成功、永久调整系统栈大小了~

调整 InnoDB 引擎的缓冲区大小

今天的船新崩坏发生在 2:30 左右(当时我可能还在外面浪……),回来一看博客上不了了。马上去看 MySQL 日志(/var/log/mysqld.log),但是并没有看到明显的 Error 信息,只看到一行行 Note 信息,然后就莫名其妙停住了……

仔细看发现这样一行信息:

2018-07-22 14:35:27 11124 [Note] InnoDB: The log sequence numbers 146002231 and 146002231 in ibdata files do not match the log sequence number 246597872 in the ib_logfiles!
2018-07-22 14:35:27 11124 [Note] InnoDB: Database was not shutdown normally!
2018-07-22 14:35:27 11124 [Note] InnoDB: Starting crash recovery.
2018-07-22 14:35:27 11124 [Note] InnoDB: Reading tablespace information from the .ibd files...

也就是说 MySQL 服务没有正常关闭……上网 Google 了一下,据说是 MySQL 因为占用内存过大(谁让一群小伙伴的网站都放在我服务器上),被系统杀掉了……然后它就频繁自己重启。查看了 kernel 日志(/var/log/messages-20180722)后发现最后有两行:

Jul 19 09:11:40 host kernel: Out of memory: Kill process 25818 (mysqld) score 249 or sacrifice child
Jul 19 09:11:40 host kernel: Killed process 25818 (mysqld) total-vm:912520kB, anon-rss:106360kB, file-rss:1876kB, shmem-rss:0kB
Jul 19 09:11:40 host kernel: oom_reaper: reaped process 25818 (mysqld), now anon-rss:4kB, file-rss:20kB, shmem-rss:0kB

果然是被系统杀掉了……

我采用的解决办法是调整 InnoDB 引擎的缓冲区大小,因为在 appnode 的 MySQL 服务管理中并没有提供调整这个的选项,关于 MySQL 的其他参数都调很小了。首先 vi /etc/my.cnf,根据指导加上:

innodb_buffer_pool_size = 64M

接下来应该 OK 了……(害怕)

本文采用 BY-NC-SA 3.0 协议进行授权。

欢迎转载,如有错误欢迎指出。

本文链接:https://skywt.cn/posts/beng/


我们的征途是星辰大海。