问使用/var/log/消息调试内存不足

EN

在此之前，内核将记录大量内容，但大部分内容可能不在/var/log/messages中，这取决于(r)syslogd的配置方式。尝试：

grep oom /var/log/*
grep total_vm /var/log/*

前者应该出现很多次，而后者只出现在一两个地方。这就是你想看的文件。

在一个也包含total_vm的文件中找到原始的“内存不足”行。在这一行之前，三十秒到一分钟(可能更长，可能更短)，你会发现如下所示：

kernel: foobar invoked oom-killer: gfp_mask=0x201da, order=0, oom_score_adj=0

您还应该在该行和“内存不足”行之间找到一个表，其标题如下：

[ pid ]   uid  tgid total_vm      rss nr_ptes swapents oom_score_adj name

这可能不会告诉您比您已经知道的更多的信息，但是字段是：

• pid进程ID。
• uid用户ID
• tgid线程组ID。
• total_vm虚拟内存使用(在4 kB页面中)
• rss驻留内存使用(在4个kB页面中)
• nr_ptes页表条目
• 交换项
• oom_score_adj通常为0；一个较低的数字表示在调用OOM杀手时进程不太可能死亡。

你可以忽略nr_ptes和swapents，尽管我相信这是决定谁被杀的因素。这不一定是使用最多内存的过程，但很可能是这样。有关选择过程的更多信息，请参见请看这里。基本上，最终得到最高oom分数的过程被扼杀了--这就是“内存不足”线上的“分数”；不幸的是，其他分数没有被报告，但该表提供了一些因素方面的线索。

同样，这可能只会说明显而易见的事情:系统内存耗尽，而mysqld被选择去死，因为杀死它会释放出最多的资源。这并不意味着mysqld做错了什么。您可以查看表，看看当时是否有其他错误，但可能没有任何明确的罪魁祸首:系统可能会因为错误地判断或配置运行的进程而耗尽内存。

关键在于消息本身--内存不足。当Linux内核缺乏虚拟内存(物理RAM和交换)时，它将开始杀死进程，这正是这里所发生的事情。看起来mysqld使用的虚拟内存超过2GB。

这个系统有多少内存和交换空间？我会考虑增加额外的RAM，或者，如果不可能的话，增加额外的交换。作为至少防止进程终止的快速修复，您可以添加一个交换文件。

更新:查看您拥有的RAM数量，您可以立即看到问题。您有1.6GB的内存和100 is的交换空间，但是MySQL使用的内存要多得多。这就解释了为什么要看到进程被终止。