1
Famio OP 忘记说明时间,从 10 月 4 日凌晨 0 点 38 分开始 down 的
|
2
hjc4869 2016-10-04 02:34:35 +08:00
内存不足,建议不要用 innodb 引擎,或者加配置
|
3
charm 2016-10-04 05:07:28 +08:00 1
内存不足,可以尽量调低缓存池大小 innodb_buffer_pool
参考: https://discuss.erpnext.com/t/mysql-mariadb-crashing-on-do-centos7-solved/3864/2 |
4
msg7086 2016-10-04 05:23:05 +08:00 1
加上交换分区试试。我不知道你所说的万网的「虚拟主机」(应该是 VPS 吧?)是什么情况,不过 InnoDB 对内存虚拟空间的要求很大,如果你虚拟空间太小的话 MySQL 是没有办法正常启动的。
|
5
eoo 2016-10-04 08:33:55 +08:00 via Android
我都是禁用 innodb
|
6
Felldeadbird 2016-10-04 09:04:07 +08:00 via iPhone 1
把你 my.cnf 我贴出来,我估计你是没有做内存限制,导致 sql 查询时占用了大量的内存,同时其他操作需要内存时触发了 linux 的内存机制把他 kill 了
|
7
Famio OP 感谢各位回复,问题已经解决了:
原来没用 swap 分区,新增了一个 swap 分区 将 buffer 调整为 64MB 目前看起来一切正常,确实是 sql 吃内存吃太多了 |
8
msg7086 2016-10-04 11:50:09 +08:00
@Famio 进程有一个「使用内存」和一个「申请内存」。
你平时看到的进程内存占用都是「使用内存」,但是触发 Kill 的却是「申请内存」。 所以你会发现明明内存还有空余,却报内存不足。 Linux 和 Windows 都是这样子的。 Windows 你可以看有个提交内存, Commit Charge ,这个就是「申请内存」。 如果 Windows 下不开分页文件,那么申请内存就等于物理内存,这种情况下内存还没用满就会提前导致系统去杀进程了。 Linux 有个内核参数可以控制 Over Commit ,有兴趣的话可以当做扩展阅读。 https://www.kernel.org/doc/Documentation/vm/overcommit-accounting |