我正在运行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的物理内存),但我的仙人掌内存图看起来对我来说…
一位朋友在这里纠正了我; 他指出图表实际上是倒置的,因为紫色表示无记忆 (不是标题所暗示的内存)。

但是奇怪的是,在内核崩溃之前,负载图会通过屋顶:

我可以查看哪些日志以获取更多信息?
也许值得注意的是 – 在崩溃时CPU百分比和networkingstream量图都是正常的。 唯一的exception是平均负荷图。
我认为这是在我部署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 killed的OOM killed 。 这可能会说明哪个进程是OOM杀手的目标。 另外请看下面的内容:
http://lwn.net/Articles/317814/
和
http://linux-mm.org/OOM_Killer
这个系统做什么? 你在同一时间用尽了交换吗? 它看起来像rsyslogd是问题,根据您的外部链接详细的崩溃。 这可能是一个定期重新启动的应用程序会很方便的情况。
2.6.18是一个非常古老的内核。 我遇到了一些问题,在某些情况下可能触发内核中的无限循环,导致从内存耗尽到I / O带宽被完全耗尽的任何事情,在无限循环中冲刷相同的数据到磁盘(这导致负载尖峰,但是正常的CPU使用。)
这些bug在被报告后很快就会得到修复,所以内核升级是一个简单的解决方法 – 再加上升级内核意味着你可以免费使用一些安全修复程序:-)
在另一个说明中,不要忘记,在一定的分辨率(收集默认为5秒仙人掌等graphics,我相信默认30秒仙人掌),所以你有一个30-60秒,不一定出现在你的图表…如果系统完全陷入停顿,这也会影响数据收集守护进程。
您可能会在日志文件中find其他有用的信息,它们是/ var / log / messages或特定于服务的/var/log/apache2/error.log。
如果你不能,那么我build议你去看看你的服务(我注意到上面的日志提取中的apache2),并validation它们是否能够导致服务器上的内存耗尽情况。 (例如:默认的apacheconfiguration,mod_prefork和php应该能够让你的系统停下来)。