EC2でWordPressを運用していた時のこと。HUGOに移行したからもう関係ないけど。

AWS（EC2）で運用しているWordPressでエラー

AWS（EC2）で運用しているWordPressの管理画面から画像をアップロードしたところエラーに。。

何度やってもエラーになるので、サーバ（EC2:t3.micro）にSSHで接続しnginxのステータスを確認。

# systemctl status nginx.service

特に問題なく思え、AWSのマネジメントコンソールで各種ステータスを確認するも問題なし。

サイトを確認すると、50xのエラーに。。

特に何をしたわけでもなく、nginxに問題がないのであればMySQLかなと思いステータスを確認。

# systemctl status mysqld.service

なぜか落ちてる。。ので起動してみるも起動せず。。

mysqlのログを確認。

# cat /var/log/mysqld.log
〜略〜
2019-09-xxxxx:xx:xx.375077Z 0 [ERROR] InnoDB: mmap(137428992 bytes) failed; errno 12
2019-09-xxxxx:xx:xx.375088Z 0 [ERROR] InnoDB: Cannot allocate memory for the buffer pool
2019-09-xxxxx:xx:xx.375091Z 0 [ERROR] InnoDB: Plugin initialization aborted with error Generic error
2019-09-xxxxx:xx:xx.375097Z 0 [ERROR] Plugin 'InnoDB' init function returned error.
2019-09-xxxxx:xx:xx.375101Z 0 [ERROR] Plugin 'InnoDB' registration as a STORAGE ENGINE failed.
2019-09-xxxxx:xx:xx.375104Z 0 [ERROR] Failed to initialize builtin plugins.
2019-09-xxxxx:xx:xx.375107Z 0 [ERROR] Aborting

という事で、メモリ不足っぽいので状況確認。

# free 
total used free shared buff/cache available
Mem: 980388 606572 187024 35724 186792 183868
Swap: 0 0 0<

あまり気にしてなかったのですが、t3.microはメモリが1GBなのに加えてスワップがないので、取り急ぎスワップの作成を実施。

# dd if=/dev/zero of=/swapfile bs=1M count=1024
1024+0 レコード入力
1024+0 レコード出力
1073741824 バイト (1.1 GB) コピーされました、 6.82985 秒、 157 MB/秒

# mkswap /swapfile
mkswap: /swapfile: パーミッション 0644 は安全な値ではありません。 0600 をお勧めします。
スワップ空間バージョン 1 を設定します。サイズ = 1024 MiB (1073737728 バイト)
ラベルはありません, UUID=0d04ab2a-821f-4ee6-831a-f0a30589a257

パーミッションで怒られたので、言われたとおりにchmodしてメモリの確認。

# chmod 600 /swapfile
# free
total used free shared buff/cache available
Mem: 980388 605816 62992 35724 311580 181552
Swap: 1048572 0 1048572

スワップ領域ができているので、MySQLを起動してみる。

# systemctl start mysqld.service

問題なく起動できたので、再度メモリの確認。

# free
total used free shared buff/cache available
Mem: 980388 797672 68484 35480 114232 26148
Swap: 1048572 2048 1046524

ということでSwap領域を作って起動できたのは良いのですが、そもそもSwapを使うのもどうかと思うので、php-fpmの設定を見直し。

# vi /etc/php-fpm.d/www.conf
~~ 
pm.max_children = 10 
pm.start_servers = 5 
pm.min_spare_servers = 5 
pm.max_spare_servers = 10 
~~

で、再起動してからSwapの解放

# systemctl restart php-fpm.service
# systemctl restart nginx.service
# swapoff -a && swapon -a

再度メモリの確認

# free
total used free shared buff/cache available
Mem: 980388 342084 415760 26444 222544 457568
Swap: 0 0 0

ということで。。

・

・

・

ん？

Swap領域がなくなっている？？

swapoffで無効化したからか。。＿|￣|○

・

・

・

気を取り直して、

# dd if=/dev/zero of=/swapfile bs=1M count=1024
1024+0 レコード入力
1024+0 レコード出力
1073741824 バイト (1.1 GB) コピーされました、 6.56543 秒、 164 MB/秒
# mkswap /swapfile
スワップ空間バージョン 1 を設定します。サイズ = 1024 MiB (1073737728 バイト)
ラベルはありません, UUID=ad6b7ada-c4ca-4b6b-a2cf-1d053fda1b05
# chmod 600 /swapfile
# swapon /swapfile
# free
total used free shared buff/cache available
Mem: 980388 330720 70592 26444 579076 463924
Swap: 1048572 0 1048572

はい。。

まとめ

EC2で運用しているMySQLが急に（いつの間にか）落ちて（お亡くなりになって）いる場合、メモリ不足が原因であることが考えられます。

その際はいったんSwapを作成して起動させて復旧したのち、設定値を見直して出来るだけSwapを使わないように、状況によっていはインスタンスタイプを変える、RDSを検討する、ことも必要かもしれません。

お金かかるけど。。

HUGOならDBいらないし、不要なトラブルもなく、費用も気にしなくてよいですけどねｗ