WordPressをEC2のt3.nanoで稼働してたらMySQLがOut of memoryになった話

  • 2022.02.16
  • AWS
WordPressをEC2のt3.nanoで稼働してたらMySQLがOut of memoryになった話

はじめに

bitnamiのWordPressをEC2のスポットインスタンスのt3.nanoで稼働していたところ、急にデータベース接続エラーになってしまいWordPressが使えなくなってしまいました。

原因を調査していたところMySQLサーバーが起動していなく、起動しようと思ったら起動できずに苦戦したという話です。

対応したこと

いつものようにWordPressに接続しようとしたところ次のエラーがでました。

データベース接続の確立中にエラーが発生しました。

これは何が起きたんだということで、WordPressとかの再起動を試みます。

# /opt/bitnami/ctlscript.sh stop apache
# /opt/bitnami/ctlscript.sh start apache

ですが、相変わらず変化はなし。EC2を再起動しても解消せず。

https://aws.amazon.com/jp/premiumsupport/knowledge-center/lightsail-wordpress-fix-database-errors/

そこで、このドキュメントを参考に調査しました。

# test ! -f "/opt/bitnami/common/bin/openssl" && echo "Approach A" || echo "Approach B"
Approach B
# test -d /opt/bitnami/mariadb && echo "MariaDB" || echo "MySQL"
MySQL

これでMySQLサーバーだったってことがわかりました。(今更感ですが、、、)

# /opt/bitnami/ctlscript.sh status mysql
mysql not running
# /opt/bitnami/ctlscript.sh start mysql

/opt/bitnami/mysql/scripts/ctl.sh : mysql  could not be started
Monitored mysql

MySQLサーバーが起動してくれません。。

# /opt/bitnami/ctlscript.sh status
php-fpm already running
apache already running
mysql not running

wordpressとかphp-fpmは起動しているようです。

# less /opt/bitnami/mysql/data/mysqld.log
2022-02-15T17:41:21.287090Z 0 [System] [MY-010910] [Server] /opt/bitnami/mysql/bin/mysqld.bin: Shutdown complete (mysqld 8.0.17)  MySQL Community Server - GPL.

ログにも大した情報はでていません。。
そこでsyslogを見ることにしました。

Feb 16 00:29:17 ip-192-168-0-150 kernel: [  191.291049] Out of memory: Kill process 3210 (mysqld.bin) score 331 or sacrifice child
Feb 16 00:29:17 ip-192-168-0-150 kernel: [  191.297516] Killed process 3210 (mysqld.bin) total-vm:253092kB, anon-rss:161144kB, file-rss:1488kB

OOM Killer にmysqlがkillされているようです。これが原因か!

ということでmy.cnfとかいじって乗り切ろうとしたのですが、起動してくれませんし、よくわかりません。

行く行く調べてみるとSwap領域がないから、こうなるっていう情報を見つけました。

SWAP領域割り当て

# df -h
Filesystem      Size  Used Avail Use% Mounted on
udev            226M     0  226M   0% /dev
tmpfs            47M  3.2M   44M   7% /run
/dev/nvme0n1p1  9.7G  9.1G  561M  95% /
tmpfs           234M     0  234M   0% /dev/shm
tmpfs           5.0M     0  5.0M   0% /run/lock
tmpfs           234M     0  234M   0% /sys/fs/cgroup
/dev/loop2       56M   56M     0 100% /snap/core18/2253
/dev/loop0       34M   34M     0 100% /snap/amazon-ssm-agent/3552
/dev/loop1       56M   56M     0 100% /snap/core18/2284
/dev/loop3      100M  100M     0 100% /snap/core/11993
/dev/loop4       25M   25M     0 100% /snap/amazon-ssm-agent/4046
/dev/loop5      111M  111M     0 100% /snap/core/12603
tmpfs            47M     0   47M   0% /run/user/1000

ただ、ディスク領域は10GiBしかないので、かなり厳しい状態です。料金をケチってる所為ですね。。。

いったん248MiBのSWAP領域を割り当てたのですが、すぐに100%になってしまい結局OOM Killer にKillされるという結果となったため、ギリギリの512MiBを攻めることにしました。

# dd if=/dev/zero of=/swapfile bs=1M count=512
# chmod 600 /swapfile
# mkswap /swapfile
# swapon /swapfile
# swapon -s
Filename				Type		Size	Used	Priority
/swapfile                              	file    	524284	502136	-1
# free -h
              total        used        free      shared  buff/cache   available
Mem:           466M        298M        7.3M         39M        160M         95M
Swap:          511M        486M         25M

かなり際どいところで動いています。。

# vi /etc/fstab

一応fstabにも次の行を追加しておきます。

/swapfile swap swap defaults 0 0

もう少し今後の対策は考えなきゃ