使用/ var / log / messages调试内存不足

我的消息日志中将引发以下报告：

kernel: Out of memory: Kill process 9163 (mysqld) score 511 or sacrifice child
kernel: Killed process 9163, UID 27, (mysqld) total-vm:2457368kB, anon-rss:816780kB, file-rss:4kB

不管这个问题是针对还是无关紧要httpd，但我很好奇如何继续调试该问题。mysqldpostfix

我如何获得有关为什么PID 9163被杀死的更多信息，并且我不确定Linux是否将终止的PID的历史记录保存在某处。

如果您的消息日志文件中出现这种情况，您将如何逐步解决此问题？

# free -m

             total       used       free     shared    buffers     cached
Mem:          1655        934        721          0         10         52
-/+ buffers/cache:        871        784
Swap:          109          6        103`

在此之前，内核会记录很多东西，但是大多数情况可能不会记录在内核中/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

您还应该在该行和“ Out of memory”行之间的某处找到一个表，其标题如下：

[ 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页表条目
• swapents掉期项
• oom_score_adj通常为0；较小的数字表示调用OOM杀手时该进程不太可能死。

您几乎可以忽略nr_ptes，swapents尽管我相信这些是确定谁被杀的因素。这不一定是使用最多内存的过程，但很有可能是这样。有关选择过程的更多信息，请参见此处。基本上，以最高oom得分结束的过程被杀死了-这就是“内存不足”行中报告的“得分”；不幸的是，没有其他分数的报告，但是该表提供了一些有关因素的线索。

再说一次，这可能只不过说明了显而易见的事情：系统内存不足并mysqld选择了消亡，因为杀死它会释放最多的资源。这并不一定意味着mysqld做错了什么。您可以查看表以查看当时是否有其他任何异常，但是可能没有明确的罪魁祸首：系统可能由于错误判断或错误配置了正在运行的进程而耗尽了内存。

关键在于消息本身- 内存不足。当Linux内核缺少虚拟内存（物理RAM和交换空间）时，它将开始杀死进程，而这正是这里发生的情况。似乎mysqld正在使用超过2GB的虚拟内存。

系统有多少RAM和交换空间？我会考虑添加额外的RAM，或者如果不可能的话，添加额外的交换。作为至少可以防止进程终止的快速解决方案，您可以添加交换文件。

更新：查看您拥有的RAM数量，您可以立即发现问题。您拥有约1.6GB的RAM和100MB的交换空间，但MySQL使用的RAM远远超过此数量。这就解释了为什么您看到进程被终止。