OOM killerとはなんぞ！？へのコメント

type74 より

type74 — Sun, 14 Feb 2010 16:55:57 +0000

反応が多いとこみると、みなさんOOM killerでお困りのようですね。。。
shared memoryを贅沢に利用するpostgresqlは、OOM killerの大好物だとか。

いずれにしよ、OOM　killerが働く場合って、
ｓｗａｐまで食いつぶしている状態なんで、プログラムに問題があるか、
性能に問題があるかの二択なんで、ちゃんと運用できてれば防げるのかもですね。。。。

ささきんぐ — Wed, 10 Feb 2010 03:42:10 +0000

サーバエンジニアやってらっしゃったんですね＾＾
俺も一緒ですｗ

OOM Killerは俺も昨年の夏頃に思いっきり悩まされた口です。
結局はOOM Killerを停止してmonitでプロセス監視して
メモリ使用適正量と言うか閾値を計算して超過したらプロセス自動再起動＆通知をするようにしてメモリリークを無くすようにしました・・・

おいらの場合はrubyのアプリケーションサーバで発生しててmongrelがめっちゃメモリ食いつぶしてしまう状態だったのでmongrelをmonitで重点監視して落ち着きましたけど・・・

まぁSNSサイトだったので、そこまで高可用性は求められなかったのですが・・・
ビジネスで使うサーバとかだとキツイかもですよね・・・

あとOOM Killerはpostgreと相性悪いと言うか重点的に狙われるって噂を聞きました・・・
MySQLユーザーなので検証したこと無いんですが・・・

type74 — Mon, 08 Feb 2010 12:36:32 +0000

まぁ、クラスタシステムとかの場合は、かえって中途半端に死ぬより、
そのまま全部死んでくれた方が良い場合もあるからなー

OOM killerを使うかは動かすシステムによりけりだにゃ。

mag — Fri, 05 Feb 2010 00:21:12 +0000

なかなか曲者だよね、OOM Killer。
カーネル設計者からすれば、アプリがメモリ食いつぶしたお陰でOSごと死んでしまうのが一番避けたいところだと思う。転ばぬ先の杖というか。

なので使う側は「OOM Killerを切る」ことよりも、swapを監視してちょっとでも使われたら何らかの措置を取る（最悪、アラームを出す）ようにしておくのが大切だね。アプリがメモリ使い続けたらアウトな訳だし。
まぁ、発想自体は事後対応っいうて点でOOM Killerと同じかな…ｗ