mysqld背后的杀手OOM

上周处理一个现场数据迁移，当时选择用开源的kettle工具做的，因为要做较多的字典值转换工作，为了省事所以选择的kettle。

在公司测试好后，远程到现场迁移数据。发现迁移1个多小时后数据库就挂掉了。查看数据库日志，没用报什么错误和有用信息，mysqld进程直接就挂掉了，然后被守护进程拉起来了。

日志如下：

后来查看系统日志，发现是被OOM干掉的。

为什么会出现这种情况呢？

我们mysql默认存储引擎使用的是tokudb引擎，我们通用的安装没有配置tokudb_cache_size，数据库会默认的设置为一半操作系统内存。

在其他点mysql都是单独一个服务器，不会有什么问题。这个点mysql和很多服务共用一个服务器，其他程序也占用较多内存，这个时候mysql还是默认的占用一半内存，当内存不够时被操作系统kill掉了。具体为啥会选择杀死mysqld,以及关于OOM的原理可以看另一片文章（Linux下OOM Killer机制详解(一)）。

这里的解决方法是配置了tokudb_cache_size，从默认的16G（一半内存），调整到了10G。之后再没出现过OOM现象。其实还有一些其他办法具体可以看。（Linux下OOM Killer机制详解(二)）。但是限制内存，肯定是比较好的办法。如有用这个文章中方法不让OOM去杀死mysql进程，它会去杀死其他的进程来释放内存。你也不知道他会杀死谁，后果可能比较严重。