発端
muninのmemoryで「commited」が頻繁に増えるので、サーバーを増強しないといけないんじゃないかって話になった。
でも、muninのcommittedの説明を読むと、
「プログラムに割り当てられたメモリ量。オーバーコミットなら正常で、メモリリークも検出できるよ」(意訳)
って書いてあったので、もしかしたら増強必要ないんじゃね？と思ったのがきっかけ。
オーバーコミット？？
- Linuxのメモリ管理サブシステム。
- プロセスに対してmallocで仮にメモリを割り当てる。
- 実メモリより多く割り当てることもある。
- 実際にプロセスが動く場合は実メモリが割り当てられる。
- スワップメモリが少ない場合、サーバーシャットダウンの恐れがある。
- 上記を回避するにはスワップメモリ以上のオーバーコミットは設定しない。
なんでこんな機能があるのか
…よくわからなかった。
とりあえず少ない物理メモリを効率的に使うためのモノらしい。
専門じゃないからわからぬ。
設定を確認する
↓のコマンドを打つ。
sysctl -a | grep vm.over
こんなん返ってくる
vm.overcommit_memory = 0
vm.overcommit_ratio = 50
- vm.overcommit_memory：オーバーコミットするかどうかの設定(下表参照)
- vm.overcommit_ratio：vm.overcommit=2のときに使う設定値
| 項目 | 内容 |
|---|---|
| 0 | オーバーコミット有効。 実メモリの大きさまで割り当てる。 |
| 1 | オーバーコミット有効。 実メモリ以上に割り当てる。 |
| 2 | オーバーコミット無効。 割り当ては下式のように割り当てる。 (0.5 * RAM) + (overcommit ratio * RAM) = Recommended swap size |
※式は公式を参照→Red Hat Customer Portal
結局問題あるのか。
この項は個人的な考察です。
現状の設定内容
現状の設定内容は
- vm.overcommit_memory = 0
- vm.overcommit_ratio = 50
こんな感じ。
実メモリ以上に割り当てない設定なので問題ないんじゃないかなーと思っている。
あるサーバーではmuninのcommittedが高くなるのに別サーバーではそうでもない
あるサーバーではcommittedが何度も実メモリ分までグラフがビンビンしてたけど、
もう片方のサーバーではappのメモリに沿って低めの値になってた。
これに対する予想。
プロセス数の違い？
- 問題がなかったサーバー→約100個のプロセスが常時起動(root/grep除く)
- 問題のあったサーバー→5個ぐらいのプロセスが常時起動(root/grep除く)
ちなみにプロセス数は下記コマンドで確認した。
ps aux | grep -v "\(root\|grep\)" | wc -l
わからなかったこと。
メモリリークの検出がmuninのcommittedでわかるって書いてあったけど、実際どんな状態になるのかわからん。
メモリリークってプロセスがメモリを解放しない状態のことだから、committedが減っていくってことなのかな…とは思ってる。
全体的に参考にさせていただいたとこ→passingloop • Linux のオーバーコミットについて調べてみた