☰

カーネルの out_of_memory エラーの原因は何ですか?

tag-icon • tag-icon linux kernel memory-usage
カーネルの out_of_memory エラーの原因は何ですか?

走っています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

サーバーのメモリが実際に不足しているのではないかと思いましたが (物理メモリは 1 GB あります)、Cacti のメモリ グラフは問題ないように見えます...

友人がここで私を訂正してくれました。グラフは実際には反転しており、紫色はメモリ空き(タイトルが示すようにメモリは使用されません)。

メモリ使用量グラフ

しかし不思議なことに、カーネルがクラッシュする直前に負荷グラフが急上昇します。

平均負荷グラフ

さらに詳しい情報を得るにはどのログを確認すればよいですか?

アップデート：

注目すべき点としては、クラッシュ時に CPU 使用率とネットワーク トラフィック グラフは両方とも正常だったことです。唯一の異常は平均負荷グラフでした。

アップデート2:

これは Passenger/Ruby をデプロイしたときに発生し始めたと思います。Rubytopがメモリの大部分とかなりの量の 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 に気付きました)、サーバー上でメモリ不足の状況を引き起こす可能性があるかどうかを確認することをお勧めします。 (例: mod_prefork と php を使用したデフォルトの apache 構成では、システムを停止させる可能性があります)。

関連情報