先日新たにソフトウェアをインストールしたときの話です。
そのインストールしたソフトウェア自身は何事もなく動作するようになったのですが、
その後、何かコマンドを実行したときに
fork: Cannot allocate memoryと表示されエラーするようになりました。
メモリ不足っぽいのですが"free"の実行結果ではまだまだメモリがあります。
おかしいなと思いつつとりあえずリブートしてみようと、
まず"su -"を実行したところ同じエラーが出て失敗します。
いや、正確に言うとユーザはrootに変わっているようなのですが、
シェル(bash)が動作していないようにも見えます。
rootになれないのでrebootができないという非常事態です。
とりあえず別のターミナルからsshで新たにログインしようとすると
shell request failed on channel 0となりやはり失敗します。
最後の手段ということでMyDTIにログインして
[ ServersMan@VPS Entryプラン]メニューの[起動/停止]ボタンで再起動して
元のとおりに復活できました。
ところが1時間ほどすると同様の症状になってしまいます。
こうなると新たにインストールしたソフトウェアが悪いことは想像に難くなく、
とりあえずそれを終了し、
その後の動作が安定していることを確認しました。
そもそもなぜメモリがあまっているのにメモリ不足といわれたのか気になり
いろいろ調べていたところ、
# grep privvmpages /proc/user_beancounters | awk '{ print int(($4-$2)*4/1024) }'
の実行結果で表示される値が残りメモリ(単位:MB)というような記述が見つかります。しかし、私の環境ではメモリが足りなくなっているようには見えません。
仕方がないので詳細を調べていくと、
OpenVZ系のゲストOS上では"/proc/user_beancounters"で
仮想マシンの状況を得られることがわかりました。
# cat /proc/user_beancountersの実行結果を見ると各項目の状態を見ることができ、
どうも現在値、今までの最大値、防御値、限界値が書いてあるっぽいです。
先の情報でいうとprivvmpages項目がメモリ状況のようで、
防御値と現在値の差に4を乗じた値がメモリの残量(単位:KB)であることが推察できます。
そこで、"/proc/user_beancounters"を丁寧に見ていくと…
ありました、numprocが上限の120あたりに張り付いています。
新しくインストールしたソフトウェアを停止すると80ほどに減ります。
つまり同時起動しているプロセスが多すぎることが原因だったんですね。
原因が分かったのはいいのですが、
どうやって回避するのかは別の話で、さてどうしたものか。
squidは設定ファイル"squid.conf"の
"auth_param digest children"の数を減らすことで対応できましたが、
その他については方法が見つかりませんね。
さくらのVPSにでも移れば制限がなくなるのでしょうか?
ちなみにプロセス数は"ps"の"m"オプションで確認できそうです。
"ps axm"で表示されるプロセス数をカウントし、
そこからPIDが"-"でなく数字になっているものの数を引くと、
"/proc/user_beancounters"のプロセス数と同じになるっぽいです。
0 件のコメント:
コメントを投稿