☰

什麼會導致核心記憶體不足錯誤？

tag-icon • tag-icon linux kernel memory-usage
什麼會導致核心記憶體不足錯誤？

我在跑Debian GNU/Linux 5.0我遇到了來自核心的間歇性記憶體不足錯誤。伺服器停止回應除 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

答案1

檢查日誌訊息中是否有內核內存不足殺手的指示，或者OOM killed在dmesg.這可能會表明哪些進程是 OOM 殺手的目標。另請查看以下內容：

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

和

http://linux-mm.org/OOM_Killer

這個系統有什麼作用？您是否同時耗盡交換空間？根據您詳細描述崩潰的外部鏈接，看起來 rsyslogd 是問題所在。在這種情況下，定期重新啟動應用程式可能會很方便。

答案2

2.6.18 是一個非常舊的核心。我遇到過一些問題，某些條件可能會觸發核心中的無限循環，從而導致從記憶體耗盡到I/O 頻寬完全用完，在無限循環中將相同的資料刷新到磁碟（這會導致負載峰值，但CPU 正常）使用。

這些錯誤往往在報告後很快就會修復，因此核心升級是解決此問題的簡單方法 - 而且升級核心意味著您可以免費獲得一些安全修復:-)

答案3

另一方面，不要忘記Cacti 和類似的圖表在一定的分辨率下（collectd 默認情況下是5 秒，cacti 我相信默認情況下是30 秒），所以你有一個30-60 秒的時間段，不一定會顯示在你的螢幕上。

您可能會在日誌檔案中找到其他有用的信息，無論是常規的 /var/log/messages 還是特定於服務的 /var/log/apache2/error.log。

如果您不能，那麼我建議您檢查您的服務（我在上面的日誌摘錄中註意到 apache2 ）並驗證它們是否能夠在您的伺服器上導致記憶體耗盡情況。 （例如：預設的 apache 配置，使用 mod_prefork 和 php 應該能夠使您的系統停止運作）。

相關內容