Google Compute Engineのmicroインスタンス（f1-micro）上のサービスが安定せず、何度再起動しても数日でハングアップする、という挙動に遭遇しました。
dockerがコンテナごと終了するケースが多発し、またVMごとハングアップすることもありました。
結論から言うと、swap領域を設定していなかったため、600MBの物理メモリを使い切った瞬間にプロセスが停止していました。
環境を切り分けて安定稼働して欲しい目的でコンテナを使うのですが、コンテナは１プロセスに過ぎないので、ホストOSの必要性しだいで簡単にkillされるようです。
oom-killerの状況確認
サービス停止の原因が、メモリ不足によるプロセス停止によるものである場合、/var/log/messagesにoom-killerのログが残されます。grepで、該当の事象が起きていることを確認できます。
$ sudo grep oom-killer /var/log/messages*
> /var/log/messages:Apr 20 07:22:20 web-1 kernel: [2419156.691059] ip invoked oom-killer: gfp\_mask=0x201da, order=0, oom\_score_adj=0
> /var/log/messages:Apr 20 07:34:06 web-1 kernel: [2419863.579685] docker invoked oom-killer: gfp\_mask=0x201da, order=0, oom\_score_adj=0
> /var/log/messages:Apr 20 07:49:24 web-1 kernel: [2420781.117919] sh invoked oom-killer: gfp\_mask=0x2000d0, order=2, oom\_score_adj=0
> /var/log/messages:Apr 20 08:02:03 web-1 kernel: [2421541.313052] cron invoked oom-killer: gfp\_mask=0x201da, order=0, oom\_score_adj=0
> /var/log/messages:Apr 20 08:04:19 web-1 kernel: [2421676.217204] python invoked oom-killer: gfp\_mask=0x280da, order=0, oom\_score_adj=0
> /var/log/messages:Apr 20 08:07:58 web-1 kernel: [2421896.355548] nginx invoked oom-killer: gfp\_mask=0x201da, order=0, oom\_score_adj=0
このように、多種多様なプロセスがkillされます。
Swapfileの状況確認
Swap領域が設定されていない場合、以下のようにswaponコマンドの出力にヘッダー以外何も表示されない状況となります。
$ /sbin/swapon -s
Filename Type Size Used Priority
ほかにも cat /proc/meminfo でSwap関連の出力を見ることで、実容量の状況も確認できます。
Swap領域を追加する
Swap領域を追加する手順は通常のLinuxのOSオペレーションと同じです。もっとも制約が少ないのはスワップファイルを作成する方式で、空容量が足りていれば設定できます。
$ sudo dd if=/dev/zero of=/swapfile bs=1024K count=1024<br />
$ sudo mkswap /swapfile<br />
$ sudo /sbin/swapon /swapfile
再起動時にSwap領域を読み込んで自動的にswaponするには、/etc/fstabに以下のような設定を一行記述しておきます。
/swapfie swap swap defaults 0 0
また、I/Oを分散させるためにはSwapファイルではなく、新たにパーティションを作成してSwap領域に指定することも可能です。
これらは基礎的なLinux OS運用の範疇で、目的に応じて構成を選択する必要があります。ただ、Swap領域はあくまで補助記憶なので、あまり念入りにチューニングする対象ではないと考えられます。
補足：systemd採用ディストリビューションのswap設定
Google Compute EngineでCoreOSを起動したところ、/etc/fstabそのものが存在しないため設定に戸惑います。
結論から言うと、/etc/fstabが存在しない場合でも、従来通りの文法で一行だけの/etc/fstabを新規作成することで、CoreOSでも起動時にswapが自動的に有効になります。
CoreOSでは起動時のシステム設定にsystemdが採用されており、サービス起動だけでなくファイルシステムのmountもsystemdのunitとして設定する方式になっています。
ただ、ファイルシステムについては/etc/fstabのエントリから設定を自動生成する仕様になっているため、fstabを適切に設定することで従来と同様の動作になります。
動作確認をするには、再起動後にswaponコマンドを実行して出力を確認します。
CoreOSに限らずRedhat系のディストリビューションでもsystemdが導入されていることから、Linux運用管理の一環としてsystemdの理解を深めておくことが不可欠になっています。
Chuma Takahiro
関連記事
