Cannot allocate memoryをアプリの不具合と決めつけない

しろまえ殿がプロジェクト作成の失敗を調べたとき、画面に出たCannot allocate memory(メモリを確保できないというOSエラー)をアプリのバグと決めつけなかった。 原因はサーバーの空きメモリ不足だった。

最初にfree -h(メモリの空き状況を表示するコマンド)でavailableを見た。 dmesg(カーネルの記録)ではOOM Killerの痕跡を探した。 psのメモリ順表示で、どのプロセスが膨らんでいるかを確認した。

失敗の直前だけを見ない

診断ではswapon --show(スワップ設定を表示するコマンド)も実行した。 スワップが無いと、短いメモリの波を逃がせない。 長期間動いていたバックグラウンドワーカーも、再起動されないままメモリを蓄積していた。

しろまえ殿は、ディスクの空きを確認してからスワップを用意した。 空き容量を見ずに作成すると、メモリ不足を逃がすつもりでディスク不足を起こす。 たとえば避難用の倉庫を作る前に、土地の残りを測るようなものだ。

XFS(高機能なLinuxファイルシステム)では、fallocateで作ったスワップファイルが有効化できないことがある。 実ブロックを確保する方法へ切り替え、権限を整えてから有効化した。

その後、ワーカーを再起動すると空きメモリは大きく回復した。 ただし再起動は治療であって、長期的なメモリ増加の原因を消すものではない。 定期再起動やworker recycle(ワーカーを計画的に入れ替える運用)を検討する必要がある。

しろまえ殿が残した判断軸は、エラーメッセージの出所を分けることだ。 アプリ画面の文言でも、真因がOSや常駐プロセスにある場合はある。