また止まってました徒労日記。
Whyなぜに。
とりあえず回避策としてタイトル通りの予防線を貼ろうと思います。
現在の状態
手順だけを見に来た方は読み飛ばしてください。
サイトの問題原因は発生当初とは変わっています。
インスタンスを$3.5のメモリ512MBプランから$5の1GBプランに変更した結果、スワップ⇒連続高負荷状態によるNot Responseはなくなりました。
じゃあどうして?というとわかっていません。
発生時の状況
問題の最中にチェックし、分かっている事は以下
- sarによる各Loadは正常。
- ctlscripts.shによるモジュールステータスは3つともalready running.
- phpMyAdminで各DBのチェック&修復をしても異常なし。
- error_logに発生タイミングでの記録なし。access_logのみぷっつり切れている(アタックの様なアクセスもない)。
- 高負荷ではないためコンソールログインは正常。
サービスを再起動するだけで即直ります。
対応方針
ブラウザで開くとNot Responseになるので、おそらくApacheが初期応答すら返せない状況になっているのだと予想します。
Lighsailが数万人に実績のあるWordpress環境という事を考えると、悪いのは自分のコンテンツかテーマかプラグイン。
さしあたりプラグインを最低限レベルまで減らし、期間を置いてチェック。
止まらないか?で判断つける事にしました。
そして発生時には復旧優先。自動でサービスを再起動するようにします。
自己監視と強制復旧
自分メモです。
インスタンスごと消して「あ!」とか言いそうなので。
シェルスクリプト
/usr/local/bin/webstatchk.shを作成しました。
※2022/05/04 “-m 10″を追加。タイムアウトを設定しないと、本当に問題があるときcurlがギブアップしないため。
# .bash_profile WEBSTAT=`curl -LI dolls.tokyo -m 10 -o /dev/null -w '%{http_code}\n' -s` if [ $WEBSTAT -ne 200 ]; then logger CODE:$WEBSTAT - httpd not work sudo /opt/bitnami/ctlscript.sh restart else logger CODE:$WEBSTAT =-=-= httpd working fi
curlで自分を見て、HTTPステータスコードだけを変数WEBSTATに格納します。
それが200(正常)じゃなかったら、Bitnamiに入っているWebサービスコマンド(/opt/bitnami/ctlscript.sh)でサービスを再起動します。
またチェック実行のログをloggerコマンドで/var/log/messagesに書き残します。
所有権とパーミッションは以下の通り
$ ls -al /usr/local/bin/webstatchk.sh -rwxr-xr-x 1 bitnami bitnami 208 Apr 29 16:34 /usr/local/bin/webstatchk.sh
cron
30分おきに実行します。
$ crontab -l 0,30 * * * * /usr/local/bin/webstatchk.sh
結果
実際にフリーズが起きたようですが、ちゃんと復帰させる事ができました。
$ tail -f /var/log/messages May 5 10:59:01 ip-172 bitnami: CODE:200 =-=-= httpd working May 5 11:29:01 ip-172 bitnami: CODE:200 =-=-= httpd working May 5 11:59:01 ip-172 bitnami: CODE:200 =-=-= httpd working May 5 12:29:01 ip-172 bitnami: CODE:200 =-=-= httpd working May 5 12:59:11 ip-172 bitnami: CODE:000 - httpd not work May 5 13:29:01 ip-172 bitnami: CODE:200 =-=-= httpd working May 5 13:59:01 ip-172 bitnami: CODE:200 =-=-= httpd working
とりあえずベースラインとして、最低限プラグインのチェックを1週間続けます。
あとは少しづつ有効化⇒様子見のサイクル。
しばらくかかりそうだ・・・