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

はじめに
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
もう少し今後の対策は考えなきゃ
-
前の記事
Gitの使い方が解る git commitとCommitコメント 2021.10.31
-
次の記事
TrelloのWebhookを使ってAWS OpenSearch Serviceにカード情報を入れる 2022.04.29