linux – 什么会导致内核out_of_memory错误？

发布时间：2020-12-14 02:28:01 所属栏目：Linux 来源：网络整理

导读：我正在运行Debian GNU / Linux 5.0,我遇到来自内核的间歇性out_of_memory错误.服务器停止响应除ping之外的所有操作,我必须重新启动服务器. # uname -aLinux xxx 2.6.18-164.9.1.el5xen #1 SMP Tue Dec 15 21:31:37 EST 2009 x86_64GNU/Linux 这似乎是来自/ v

我正在运行Debian GNU / Linux 5.0,我遇到来自内核的间歇性out_of_memory错误.服务器停止响应除ping之外的所有操作,我必须重新启动服务器.

# uname -a
Linux xxx 2.6.18-164.9.1.el5xen #1 SMP Tue Dec 15 21:31:37 EST 2009 x86_64
GNU/Linux

这似乎是来自/ var / log / messages的重要部分

Dec 28 20:16:25 slarti kernel: Call Trace:
Dec 28 20:16:25 slarti kernel: [<ffffffff802bedff>] out_of_memory+0x8b/0x203
Dec 28 20:16:25 slarti kernel: [<ffffffff8020f825>] __alloc_pages+0x245/0x2ce
Dec 28 20:16:25 slarti kernel: [<ffffffff8021377f>] __do_page_cache_readahead+0xc6/0x1ab
Dec 28 20:16:25 slarti kernel: [<ffffffff80214015>] filemap_nopage+0x14c/0x360
Dec 28 20:16:25 slarti kernel: [<ffffffff80208ebc>] __handle_mm_fault+0x443/0x1337
Dec 28 20:16:25 slarti kernel: [<ffffffff8026766a>] do_page_fault+0xf7b/0x12e0
Dec 28 20:16:25 slarti kernel: [<ffffffff8026ef17>] monotonic_clock+0x35/0x7b
Dec 28 20:16:25 slarti kernel: [<ffffffff80262da3>] thread_return+0x6c/0x113
Dec 28 20:16:25 slarti kernel: [<ffffffff8021afef>] remove_vma+0x4c/0x53
Dec 28 20:16:25 slarti kernel: [<ffffffff80264901>] _spin_lock_irqsave+0x9/0x14
Dec 28 20:16:25 slarti kernel: [<ffffffff8026082b>] error_exit+0x0/0x6e

完整片段：http://pastebin.com/a7eWf7VZ

我想也许服务器实际上内存不足(它有1GB的物理内存),但我的Cacti内存图对我来说还不错……

一位朋友在这里纠正了我;他注意到图形实际上是倒置的,因为紫色表示内存空闲(不是标题所示的内存).

但奇怪的是,在内核崩溃之前不久,加载图就会通过屋顶：

我可以查看哪些日志以获取更多信息？

更新：

也许值得注意的是 – 崩溃时CPU的百分比和网络流量图都是正常的.唯一的异常是平均负荷图.

更新2：

我认为当我部署Passenger / Ruby时会发生这种情况,使用top我发现Ruby使用的是大部分内存和相当数量的CPU：

PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND            
 5189 www-data  18   0  255m 124m 3388 S    0 12.1  12:46.59 ruby1.8            
14087 www-data  16   0  241m 117m 2328 S   21 11.4   3:41.04 ruby1.8            
15883 www-data  16   0  239m 115m 2328 S    0 11.3   1:35.61 ruby1.8

解决方法

检查日志消息以获取内核内存杀手的指示,或者在dmesg的输出中被杀死的OOM.这可能会说明哪些进程是OOM杀手的目标.另请查看以下内容：

http://lwn.net/Articles/317814/

和

http://linux-mm.org/OOM_Killer

这个系统做什么用的？你是在同时耗尽交换吗？根据详细说明崩溃的外部链接,看起来似乎是rsyslogd的问题.这可能是定期重启应用程序的方式.

（编辑：李大同）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!