mysql 服务器不知为何自己挂掉了，日志如下

V2EX = way to explore

V2EX 是一个关于分享和探索的地方

已注册用户请登录

这是一个创建于 2473 天前的主题，其中的信息可能已经有所发展或是发生改变。

mysql 是装在云服务器，一直都正常运行，昨天下午四点有几百号人同时连一个网页（这个网页和后台任务并不需要连 MYSQL ）并运行一个后台 C++任务，然后今天发现昨天下午 mysql 挂了，日志如下，这是因为服务器的 CPU 和内存占用过高把 MYSQL 给挤的挂掉了吗？然后根据下面的日志显示它又没有重启成功？

但为什么其他的进程没有被挤掉呢，比如 REDIS 等都还是正常的

170712 17:29:27 [Warning] IP address '140.205.225.196' could not be resolved: Name or service not known
170713 2:10:41 [Warning] IP address '158.85.81.114' has been resolved to the host name '72.51.559e.ip4.static.sl-reverse.com', which resembles IPv4-address itself.
170713 12:25:56 [Warning] IP address '140.205.225.193' could not be resolved: Name or service not known
170713 17:13:46 [Warning] IP address '113.96.132.212' could not be resolved: Name or service not known
170714 12:49:16 [Warning] IP address '140.205.225.203' could not be resolved: Name or service not known
170715 15:31:38 [Warning] IP address '140.205.225.191' could not be resolved: Name or service not known
170716 16:37:19 mysqld_safe Number of processes running now: 0
170716 16:37:19 mysqld_safe mysqld restarted
170716 16:37:21 [Note] /usr/local/mysql/bin/mysqld (mysqld 5.5.45) starting as process 25133 ...
170716 16:37:21 [Note] Plugin 'FEDERATED' is disabled.
170716 16:37:21 InnoDB: The InnoDB memory heap is disabled
170716 16:37:21 InnoDB: Mutexes and rw_locks use GCC atomic builtins
170716 16:37:21 InnoDB: Compressed tables use zlib 1.2.3
170716 16:37:21 InnoDB: Using Linux native AIO
170716 16:37:21 InnoDB: Initializing buffer pool, size = 128.0M
InnoDB: mmap(137363456 bytes) failed; errno 12
170716 16:37:21 InnoDB: Completed initialization of buffer pool
170716 16:37:21 InnoDB: Fatal error: cannot allocate memory for the buffer pool
170716 16:37:21 [ERROR] Plugin 'InnoDB' init function returned error.
170716 16:37:21 [ERROR] Plugin 'InnoDB' registration as a STORAGE ENGINE failed.
170716 16:37:21 [ERROR] Unknown/unsupported storage engine: InnoDB
170716 16:37:21 [ERROR] Aborting

170716 16:37:21 [Note] /usr/local/mysql/bin/mysqld: Shutdown complete

170716 16:37:21 mysqld_safe mysqld from pid file /var/run/mysqld/mysqld.pid ended

10 条回复 • 2017-07-18 00:55:24 +08:00

iyaozhen

2017-07-17 20:17:36 +08:00 via Android

“ Fatal error: cannot allocate memory for the buffer pool ”
机器内存不足了？

holyghost

2017-07-17 20:18:43 +08:00

InnoDB: Fatal error: cannot allocate memory for the buffer pool

OOM
MySQL

edison111cry

2017-07-17 20:23:22 +08:00

@iyaozhen
有可能，因为后台的任务比较占内存，并且同时被起了好多个。所以 MYSQL 在机器的内存不够时会自己挂掉（即使没有程序在连接 MYSQL 数据库）？

edison111cry

2017-07-17 20:23:50 +08:00

@holyghost
所以 MYSQL 在机器的内存不够时会自己挂掉（即使没有程序在连接 MYSQL 数据库）？

privil

2017-07-17 20:46:59 +08:00

内存占用过高，被系统干掉了……

privil

2017-07-17 20:51:50 +08:00

http://www.vpsee.com/2013/10/how-to-configure-the-linux-oom-killer/ 可以看看这篇文章，讲很细了

lolizeppelin

2017-07-17 21:09:43 +08:00 via Android

看系统日志是不是系统杀掉的里面会有记录

后面是 mysql 重启的日志看样子比较像没内存 mysql 被杀掉了

为什么其他的没杀掉只杀 mysql
应该是系统策略 oom 优先杀内存占用最大的

ghostheaven

2017-07-17 21:12:11 +08:00 via Android

是 mysql 自己分配不到必要的内存，所以自己挂了吧

edison111cry

2017-07-17 22:02:56 +08:00

@privil 太感谢啦

msg7086

2017-07-18 00:55:24 +08:00

InnoDB 会占用大量的 Committed Memory，所以需要一定的 Swap 提供内存分页。
也可以修改内核的 Overcommit 参数（有副作用）。

MySQL 的内存不足问题很常见的，MySQL 本身可能只吃 100M 内存，但是会申请比如说 1G 备用。
你必须保证这个「 1G 」是可用的，否则一定会被 OOM 杀掉。
更多链接可以看我在前一个 MySQL 内存炸掉帖子里的回复。