今天打开我博客突然再次出现了 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 了……(害怕)
July 22nd, 2018 at 10:41 pm
难怪下午访问的时候崩了233333
July 23rd, 2018 at 09:45 am
wow被ZZK大佬疯狂捧场,激动
August 28th, 2018 at 02:28 pm
兹瓷天天~