このブログはAWS Lightsail上でWordPressを動かしています。

これまではBitnami版のWordPressを利用していましたが、AWSからBitnami版のサポート終了に関する案内が表示されるようになったため、新しいWordPress Blueprint環境へ移行しました。

移行作業そのものは比較的スムーズでした。

スナップショットから新しいインスタンスを作成し、All-in-One WP Migrationを利用してサイトデータを移行。DNS切り替えやHTTPS設定も完了し、サイトは問題なく表示されるようになりました。

ところが移行後、気になる症状が発生しました。

移行後に1日1回くらいサイトが落ちる

完全に再現するわけではありませんでしたが、

• WordPress管理画面へアクセスできない
• サイト表示が極端に遅くなる
• ページが開けなくなる

といった症状が発生しました。

しかも2日連続で1日1回程度発生していました。

私は個人ブログ運営なので、

「アクセスが集中してサーバーが落ちる」

という状況ではありません。

そのため、

• WordPress移行の失敗
• DNSの問題
• HTTPS設定の問題
• サーバーリソース不足

などを順番に疑っていきました。

---

まずサーバーのメモリを確認

AWSのLightsailにアクセスするとSSHを使用して接続というところでコンソールを立ち上げることができます。コマンドプロンプトのような黒い画面が見えるのでそれが自分のサーバーだと思います。Linuxコマンドにて操作、データ確認、設定変更などができます。

Linuxでは以下のコマンドでメモリ状況を確認できます。

free -h

当時調査していて気付いたのが、

スワップが設定されていなかったことです。

Linuxにはスワップという仕組みがあります。

簡単に言うと、

メモリが不足しそうになった時にSSDやディスクの一部を仮想メモリとして利用する仕組み

です。

---

Lightsailの1GB環境でスワップ無しは少し不安

私の環境はLightsailの1GBメモリプランです。

この中で、

• Apache
• MariaDB
• PHP
• WordPress
• 各種プラグイン

が動いています。

普段は問題なくても、

• プラグイン更新
• バックグラウンド処理
• 管理画面操作
• データベース処理

などが重なると、一時的にメモリ消費が増える可能性があります。

そこで念のためスワップを追加することにしました。

---

1GBのスワップを追加

実施したコマンドはこちらです。sudoというのはSuper UserがDoするみたいな感じで業務で覚えました（笑）

sudo fallocate -l 1G /swapfile
sudo chmod 600 /swapfile
sudo mkswap /swapfile
sudo swapon /swapfile

再起動後も有効になるように設定します。

echo '/swapfile none swap sw 0 0' | sudo tee -a /etc/fstab

設定後に確認します。

free -h

すると、

Swap: 1.0Gi

と表示されるようになりました。

---

その後サイトが落ちなくなった

スワップ設定後、

少なくとも私が確認している範囲では、

これまで発生していた

1日1回程度の停止

が発生しなくなりました。

もちろん、

100％スワップが原因だった

とは断定できません。

しかし、

• 停止が発生していた
• スワップが無かった
• スワップを追加した
• その後は安定

という流れを見ると、関係していた可能性は十分ありそうです。

---

本当にスワップは使われていた

後日確認してみました。

free -h

結果は次のようになっていました。

Mem:
total      945Mi
used       554Mi
free       334Mi
available  390Mi

Swap:
total      1.0Gi
used       176Mi
free       847Mi

注目したのはここです。

Swap used 176Mi

つまり、

実際に176MB程度のスワップが使用されていた

ことになります。

設定しただけでなく、本当に使われていたことが分かりました。

---

Linuxは実際にスワップを利用していた

さらに以下のコマンドで確認してみました。

cat /proc/vmstat | grep -E "pswpin|pswpout"

結果はこちら。

pswpin 83864
pswpout 177677

これは、

• pswpout：メモリからスワップへ退避した回数
• pswpin：スワップからメモリへ戻した回数

を表しています。

つまりLinuxは実際にスワップを利用しながらメモリ管理を行っていました。

---

どのプロセスがメモリを使っていたのか

さらに top コマンドで確認してみると、

主にメモリを使用していたのは、

mariadbd
apache2
apache2
apache2
apache2

でした。

WordPress環境としては普通です。

特にApacheはアクセス状況によって複数の子プロセスを起動するため、

1GB環境では意外とメモリを消費します。

---

スワップがなければ落ちていたのか？

正確には分かりません。

ただし、

• スワップ追加前は1日1回程度停止
• スワップ追加後は停止なし
• 実際に176MB使用されていた
• Linuxがスワップへ退避していた記録がある

という状況を見ると、

スワップがメモリ不足時の緩衝材として機能していた可能性は高そうです。

少なくとも、

「設定したけど全く使われていなかった」

わけではありませんでした。

---

ちなみにHTTPS設定も修正した

今回のトラブル調査では、スワップ以外にもHTTPS周りの設定を見直しました。

困りごととしてはこれまでブログ記事を書いていて、下書き保存するときに途中から動作が不安定になり、保存ボタンが動作しなくなることでした。これはBitnami環境時代もありましたし、移行後もありました。ChatGPTに相談して調べてみるとどうやら一般設定の項目に見えているURLの部分でhttpとなっていたのが問題そうだったのが分かりましたので修正に進めました。

Bitnami環境の頃からHTTPSは利用していましたし、移行後もHTTPS化自体はできていました。

ただし、WordPress側のURL設定や wp-config.php の設定を見直し、

define( 'WP_HOME', 'https://' . $_SERVER['HTTP_HOST'] . '/' );
define( 'WP_SITEURL', 'https://' . $_SERVER['HTTP_HOST'] . '/' );

を設定しました。

また、

設定
↓
一般

にある

WordPressアドレス(URL)
サイトアドレス(URL)

も確認しました。

こちらは、

• 再ログインが多い
• 管理画面が不安定
• Cookie関連の不整合

などの改善を期待して実施したものです。

ただ、今回の「1日1回サイトが落ちる問題」に関しては、スワップ追加の方が効果としては大きかったように感じています。

---

今回学んだこと

今回の件で学んだのは、

WordPressが落ちる
↓
WordPressが悪いとは限らない
↓
Linuxのメモリ管理が原因の場合もある

ということでした。

また、

スワップを使っている
＝異常

ではなく、

スワップを使うことで
サーバー全体の安定性を維持している

という面もあることが分かりました。

AWS Lightsailの1GBプランでWordPressを運用している方は、一度スワップ設定を確認してみることをおすすめします。

私の場合は、移行後に発生していた不安定な症状の調査を通じて、Linuxのメモリ管理についてかなり勉強になりました。

実際こういったように自分でサイトを運用してみるとトラブルに遭遇したり、調べて解決に向けて行動してみたりが面白いですね。Bitnamiからの移行でスワップを確認しなければいけない、設定しなければいけないというのは盲点でした。転職なんかで経験者が求められる理由が良く分かりますよね。1回でも経験して知っていると、今回のケースだと移行する時点で最初の初期設定としてみるべきポイントとして”気付く”ことができるし、もしそこでそれを行わなかったとしてもトラブルが発生した段階ですぐここを見てみようと”思考””実行”することができますよね。良い経験になりました。