2月 04
自分がOOM killerという物を知ったのはつい最近の事。
どうも、開発中のアプリがメモリリークを起こしてて、
一部の重要なプロセスが勝手に殺されたんだが、
毎回、違うプロセスがkillされるものだから不思議に思ってたんだが、
犯人はOOM killerというものらc。
OOM killerは物理メモリとswapが食いつぶされた時、
OOM killerのアルゴリズムに従ってランダムなプロセスを強制的に殺す
悪名高きメモリ解放機だとの事。
OOM killerがあれば、メモリ不足によるサーバダウンを防げるとの事だが、
殺すプロセスはランダムに近いので度々重要なプロセスを殺して結果的に
システム障害を招くので意味がない。。。。。
なんでこの物が実装されているかというと、Linux kernelのメモリ管理に深刻なバグがあるようで、
その対処としてOOM killerがあるのだとか。。。。
ちなみにmallocのmanには以下の記述がある。
デフォルトでは、Linux は楽観的メモリ配置戦略を用いている。 つまり、 malloc() が NULL でない値を返しても、 そのメモリが実際に利用可能であることが保証されない。 これは本当にまずいバグである。 システムがメモリ不足状態になったとき、 悪名高いメモリ不足解決器 (OOM killer) によって 一つまたは複数のプロセスが削除される。
重要なプロセスをOOM killerの魔の手から守るには以下のコマンドを使う
# echo -17 > /proc/<プロセスID>/oom_adj
OOM killerそのものを無効化したい場合は、/etc/sysctl.confに以下の記述を追加
vm.overcommit_memory = 2
今度、OSの設計をする機会があったら、このあたりも意識しておかないとな。。。。。。。
↓参考URL
第3部 第1回 パラメータ変更でカーネル・チューニング
この記事が気に入ったら
ソーシャルブックマーク登録BOX
|
|
|
Yahoo!ブックマークに登録 |
|
|
TrackBack URL :
2月 5th, 2010 at 09:21
なかなか曲者だよね、OOM Killer。
カーネル設計者からすれば、アプリがメモリ食いつぶしたお陰でOSごと死んでしまうのが一番避けたいところだと思う。転ばぬ先の杖というか。
なので使う側は「OOM Killerを切る」ことよりも、swapを監視してちょっとでも使われたら何らかの措置を取る（最悪、アラームを出す）ようにしておくのが大切だね。アプリがメモリ使い続けたらアウトな訳だし。
まぁ、発想自体は事後対応っいうて点でOOM Killerと同じかな…ｗ
2月 8th, 2010 at 21:36
まぁ、クラスタシステムとかの場合は、かえって中途半端に死ぬより、
そのまま全部死んでくれた方が良い場合もあるからなー
OOM killerを使うかは動かすシステムによりけりだにゃ。
2月 10th, 2010 at 12:42
サーバエンジニアやってらっしゃったんですね＾＾
俺も一緒ですｗ
OOM Killerは俺も昨年の夏頃に思いっきり悩まされた口です。
結局はOOM Killerを停止してmonitでプロセス監視して
メモリ使用適正量と言うか閾値を計算して超過したらプロセス自動再起動＆通知をするようにしてメモリリークを無くすようにしました・・・
おいらの場合はrubyのアプリケーションサーバで発生しててmongrelがめっちゃメモリ食いつぶしてしまう状態だったのでmongrelをmonitで重点監視して落ち着きましたけど・・・
まぁSNSサイトだったので、そこまで高可用性は求められなかったのですが・・・
ビジネスで使うサーバとかだとキツイかもですよね・・・
あとOOM Killerはpostgreと相性悪いと言うか重点的に狙われるって噂を聞きました・・・
MySQLユーザーなので検証したこと無いんですが・・・
2月 15th, 2010 at 01:55
反応が多いとこみると、みなさんOOM killerでお困りのようですね。。。
shared memoryを贅沢に利用するpostgresqlは、OOM killerの大好物だとか。
いずれにしよ、OOM killerが働く場合って、
ｓｗａｐまで食いつぶしている状態なんで、プログラムに問題があるか、
性能に問題があるかの二択なんで、ちゃんと運用できてれば防げるのかもですね。。。。