centOS7 上 mysql 服务经常无故 dead,有 log,请各路大神会诊

2016-10-04 01:02:05 +08:00
 Famio
查看 log 初步判断为服务自动终止,原因是内存溢出,我以前的主机是 1GB 的 ram ,以为是内存太小,升级到了 2GB ,结果还是这个问题,其实我觉得和内存大小没有太大关系,因为我用过万网的虚拟主机, 512MB 的都能跑的好好的,自从迁移到 ECS 上后就问题不断。请各位大神帮忙看下这个 log ,为何内存总是溢出,感谢!

maridb log 如下:
161003 3:45:07 [Warning] IP address '121.28.142.136' could not be resolved: Name or service not known
161003 3:45:07 [Warning] IP address '121.28.142.138' could not be resolved: Name or service not known
161003 3:45:08 [Warning] IP address '121.28.142.133' could not be resolved: Name or service not known
161003 7:05:41 [Warning] IP address '69.165.72.94' could not be resolved: Name or service not known
161003 11:37:43 [Warning] IP address '123.249.3.155' could not be resolved: Name or service not known
161003 12:28:12 [Warning] IP address '121.199.70.200' could not be resolved: Name or service not known
161004 0:10:16 [Warning] IP address '139.224.53.6' could not be resolved: Name or service not known
161004 0:19:28 [Warning] IP address '124.173.113.45' could not be resolved: Name or service not known
161004 00:38:31 mysqld_safe Number of processes running now: 0
161004 00:38:31 mysqld_safe mysqld restarted
161004 0:38:31 [Note] /usr/libexec/mysqld (mysqld 5.5.50-MariaDB) starting as process 27071 ...
161004 0:38:31 [Warning] Changed limits: max_open_files: 1024 max_connections: 214 table_cache: 400
161004 0:38:31 InnoDB: The InnoDB memory heap is disabled
161004 0:38:31 InnoDB: Mutexes and rw_locks use GCC atomic builtins
161004 0:38:31 InnoDB: Compressed tables use zlib 1.2.7
161004 0:38:31 InnoDB: Using Linux native AIO
161004 0:38:31 InnoDB: Initializing buffer pool, size = 128.0M
InnoDB: mmap(137756672 bytes) failed; errno 12
161004 0:38:31 InnoDB: Completed initialization of buffer pool
161004 0:38:31 InnoDB: Fatal error: cannot allocate memory for the buffer pool
161004 0:38:31 [ERROR] Plugin 'InnoDB' init function returned error.
161004 0:38:31 [ERROR] Plugin 'InnoDB' registration as a STORAGE ENGINE failed.
161004 0:38:31 [ERROR] mysqld: Out of memory (Needed 128917504 bytes)
161004 0:38:31 [ERROR] mysqld: Out of memory (Needed 96681984 bytes)
161004 0:38:31 [ERROR] mysqld: Out of memory (Needed 72499200 bytes)
161004 0:38:33 [Note] Plugin 'FEEDBACK' is disabled.
161004 0:38:33 [ERROR] Unknown/unsupported storage engine: InnoDB
161004 0:38:33 [ERROR] Aborting

161004 0:38:33 [Note] /usr/libexec/mysqld: Shutdown complete

161004 00:38:33 mysqld_safe mysqld from pid file /var/run/mariadb/mariadb.pid ended
3945 次点击
所在节点    MySQL
10 条回复
Famio
2016-10-04 01:03:09 +08:00
忘记说明时间,从 10 月 4 日凌晨 0 点 38 分开始 down 的
hjc4869
2016-10-04 02:34:35 +08:00
内存不足,建议不要用 innodb 引擎,或者加配置
charm
2016-10-04 05:07:28 +08:00
内存不足,可以尽量调低缓存池大小 innodb_buffer_pool
参考:
https://discuss.erpnext.com/t/mysql-mariadb-crashing-on-do-centos7-solved/3864/2
msg7086
2016-10-04 05:23:05 +08:00
加上交换分区试试。我不知道你所说的万网的「虚拟主机」(应该是 VPS 吧?)是什么情况,不过 InnoDB 对内存虚拟空间的要求很大,如果你虚拟空间太小的话 MySQL 是没有办法正常启动的。
eoo
2016-10-04 08:33:55 +08:00
我都是禁用 innodb
Felldeadbird
2016-10-04 09:04:07 +08:00
把你 my.cnf 我贴出来,我估计你是没有做内存限制,导致 sql 查询时占用了大量的内存,同时其他操作需要内存时触发了 linux 的内存机制把他 kill 了
Famio
2016-10-04 09:25:25 +08:00
感谢各位回复,问题已经解决了:
原来没用 swap 分区,新增了一个 swap 分区
将 buffer 调整为 64MB
目前看起来一切正常,确实是 sql 吃内存吃太多了
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
julyclyde
2016-10-04 17:28:56 +08:00
@msg7086 申请如果还能活着失败,说明是被内核的 over commit 给限制的;如果是使用超限,进程根本不会有感知,直接就上天了,内核日志记录 oom-killer
realpg
2016-10-05 13:05:53 +08:00
@Famio
在你的 MYSQL 配置文件里加一句
performance_schema = OFF
内存问题就解决了, 512M 内存也可以愉快的使用了

这是一个专为移动设备优化的页面(即为了让你能够在 Google 搜索结果里秒开这个页面),如果你希望参与 V2EX 社区的讨论,你可以继续到 V2EX 上打开本讨论主题的完整版本。

https://www.v2ex.com/t/310459

V2EX 是创意工作者们的社区,是一个分享自己正在做的有趣事物、交流想法,可以遇见新朋友甚至新机会的地方。

V2EX is a community of developers, designers and creative people.

© 2021 V2EX