标签：linux memory out-of-memory logs

我的消息日志中抛出以下报告：

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,mysqld还是postfix都没关系,但我很好奇如何继续调试问题.

如何获得有关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的文件中找到原始的“Out of memory”行.在该行之前的三十秒到一分钟(可能更多,可能更少)你会发现类似的东西：

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,虽然我相信这些是决定谁被杀的因素.这不一定是使用最多内存的过程,但它很可能是.有关选择过程的更多信息,请参见see here.基本上,以最高oom分数结束的过程将被终止 – 这就是“内存不足”行中报告的“分数”;遗憾的是,没有报告其他分数,但该表提供了一些因素方面的线索.

同样,这可能不会比明显更明显：系统耗尽内存并且mysqld选择死亡,因为杀死它会释放最多的资源.这并不一定意味着mysqld做错了什么.您可以查看该表以查看当时是否还有其他任何问题,但可能没有任何明确的罪魁祸首：系统可能因为您错误判断或错误配置正在运行的进程而耗尽内存.

标签：linux,memory,out-of-memory,logs
来源： https://codeday.me/bug/20190808/1622864.html

本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享；
2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关；
3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关；
4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除；
5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。