メモリ不足の時にサーバーを自動で再起動させる(AWS EC2 Ubuntu 18.04)
Contents
サーバーが応答なし
ここ数日AWS(Amazon Web Services)上のサーバー(OS:Ubuntu18.04)が2回程ダウンしてしまった。
時間は20分と58分、JectPackのプラグインで24時間監視をしているのだがサーバーが”応答なし”なって自動で回復した記録のメールが届いていた。
syslogを確認する
/var/log/syslogを確認した所、2回ともにoom-killerが発生していた事が分かった。
OOM(Out Of Memory) Killerとはメモリが枯渇した時にシステムの動作を確保するためにメモリを多く使用しているプロセスを次々と停止(kill)する仕組み。
oom-killerが発生した後のログを追ってみると何度かMy-SQLの再起動を繰り返して何とか回復した様子が伺われる。
メモリの状態
以下のコマンドでメモリの状態を確認してみる。
free -m
- 全体:978MByte
- 使用中:644BMyte
- 未使用(free):97MByte
未使用が97MByteしかない。
というか、そもそもメモリを全体で1 GByteしか積んでいない。
サーバーの構成
このブログのサーバーの情報は以下の通り。
サーバー | AWS(Amazon Web Services)EC2 |
インスタンスタイプ | t2.micro
|
OS | Ubuntu Server 18.04 LTS |
CMS | WordPress 5.4.2 |
t2.microはAWSのアカウントを作った際に最初の1年間が無料だったので選択した入門用のインスタンスタイプだ。
このブログは約8.5万PV/月あるのだが、この低スペックで今まで大きな問題なく、よく稼働していたもんだとちょっと感心した。
対応方針
そもそもサーバーのメモリサイズが少な過ぎるのでインスタンスのタイプ変更でスケールアップが必要なのだが当面の対応としてoom-killerが発生した際にはサーバーを自動で再起動させることにした。
サーバーの再起動自体は数十秒で終わるので30分近くメモリ不足で瀕死の状態で稼働させるよりも、さっさと再起動させてしまった方がWEBサーバーの停止時間は短くなるとの判断である。
まずはテスト用のVM環境を構築してテストしてみて想定通り再起動したので本番サーバーにも反映させた。
vm.overcommit_memory=1
vm.panic_on_oom=1
kernel.panic=10
反映させる。
sudo sysctl -p
下記のコマンドでストレスを与えた所、再起動されることが確認できた。(これはVMのテスト環境のみで実験している)
stress --vm 2 --vm-bytes 3333M
設定してからはまだ一度もoom-killerが発生していないので検証は出来ていない。
早めにインスタンスタイプのスケールアップは実施したいと思っている。
最近のコメント