あんまりエントリにするほどの分量はないんだけど、現時点でのオイラのオススメ値を貼っとく

overcommit_memory=2
overcommit_ratio=0
swapパーティションのサイズ：　物理メモリ量ｘ８０％

overcommit_ratio=0 にすることで、全プロセスの仮想メモリ量がスワップサイズを超えなくなるので、カーネルによほど負荷をかけないかぎりスワップしなくなる。
んで、スワップを０にしたときと違って、カーネルに負荷をかけるようなスゲー使いかたをしたときでもスワップが発生するだけでOOM-killerは発生しない。

欠点は、ほぼ使わないと想定しているスワップに結構なディスク量をとられることだけである。

あ、あと、８０％というのはかなり適当に決めた値なのでシステムによっては９０％とかでもいけると思う。


注意１：　この設定は組み込みでは全然使えません。なぜならサーバー系みたいに数Ｇのメモリを積む世界では、glibc mallocやpthreadがアドレス空間予約のために発行するmmap(PROT_NONE)な空間なんてゴミですが、全体メモリが16Mとか32Mの世界ではスタックの１スレッドあたり2Mの予約量がバカに出来ません。
たぶん、組み込みではovercommit_memoryで制御なんて思わないほうが懸命。組み込みなんだから自分でメモリ量ぐらい把握しろ。と（←出来たら苦労しねーよ）

注意２：　上記の設定は/etc/sysctl.confに設定してはいけません
大半のディストリで、sysctl.confの読み込みはswapのmountよりも前に行われるので、OSが起動しなくなります。
rc.localとかlocal.rc とか、すごーく、最後のほうに走るスクリプトがあると思うので、そのへんに
sysctl -w vm.overcommit_memory=2
のように、sysctlコマンドを使って設定するのがオヌヌメ


あと、最後に残された課題は、このほとんど使わないことが確定なスワップ領域をなんとかして、圧縮できないのかって事。
ext3ってファイルの圧縮とか出来ないんだよねー。
むむむ

過去エントリはこちら
Linuxでのovercommit_memory制御の勘所
tmpfsとstrict non-overcommit mode


まあ、結論の歯がゆさにイライラした人は↓でも見て癒されろ



そんな結論でええんかい！　ランキング！

関連記事

• MySQLがlinuxで遅いのはglibc mallocのせい？ (2007/03/17)
• で、結局overommit_memoryのオススメ設定値はいくつなのさ？ (2007/03/04)
• tmpfsとstrict non-overcommit mode (2007/03/04)