AWSでWordPressやってて頻繁にmysqlがデータベース接続確立エラーでダウンする現象の回避策

このブログはawsのサーバを使っていて完全に自前で運営してるんですが、ブログ開始から3ヶ月、4回もmysqlが落ちてブログが使えない状態になってしまいました。これが無料ブログサイトとかだったら、サービス担当者が対応してくれるところですが、自前ブログだと自分で対応しないと永遠に落ちたままです。そこら辺が自前の難しいところですが、面白いところでもあります。

エラー画面

ちなみに落ちるとこんな画面が表示されます。 真っ白な画面にデータベース接続確立エラー error20151111-2 洒落っ気もなにもあったもんじゃない。 管理画面もこんな感じになります。 error20151111

とりあえず復旧

とりあえず、復旧させるためには落ちたmysqlのプロセスを起動します。

# sudo service mysqld startStarting mysqld:                                           [  OK  ]

復旧自体はほんの2秒なんですが、落ちたことにすぐ気付かないケースも多いし、9月なんてベトナムに長期旅行中に落ちてました。会社で気付いたときも鍵がないからしばらく放置してました。

原因

# less /var/log/mysqld.log
51111 14:07:31 InnoDB: The InnoDB memory heap is disabled
151111 14:07:31 InnoDB: Mutexes and rw_locks use GCC atomic builtins
151111 14:07:31 InnoDB: Compressed tables use zlib 1.2.8
151111 14:07:31 InnoDB: Using Linux native AIO
151111 14:07:31 InnoDB: Initializing buffer pool, size = 128.0M
InnoDB: mmap(137363456 bytes) failed; errno 12
151111 14:07:31 InnoDB: Completed initialization of buffer pool
151111 14:07:31 InnoDB: Fatal error: cannot allocate memory for the buffer pool
151111 14:07:31 [ERROR] Plugin 'InnoDB' init function returned error.
151111 14:07:31 [ERROR] Plugin 'InnoDB' registration as a STORAGE ENGINE failed.
151111 14:07:31 [ERROR] Unknown/unsupported storage engine: InnoDB
151111 14:07:31 [ERROR] Aborting
# less /var/log/messages
Nov 11 14:07:31 ip-172-31-19-188 kernel: [7355293.658511] Out of memory: Kill process 23065 (httpd) score 50 or sacrifice child
Nov 11 14:07:31 ip-172-31-19-188 kernel: [7355293.661473] Killed process 23065 (httpd) total-vm:480304kB, anon-rss:50464kB, file-rss:0kB

ここから分かるのはメモリが足りなくなってmysqlプロセス落としましたってことなんですが、所詮t2.microだもんなーと思いつつも、今のたかだか1日100PVいくかいかないかくらいのアクセスでスペック上げるのもコスト的に嫌なので、なんとかしたいと思います。

とりあえず、調べてみるとswap領域が0。

# free
       total       used       free     shared    buffers     cached
Mem:       1020188     565452     454736        140      12936      90404
-/+ buffers/cache:     462112     558076
Swap:            0          0          0

スワップ 【 swap 】 メモリスワップ / memory swap

ハードディスクなどの補助記憶装置を利用して使用可能なメモリ容量を増やすOSの機能の一つ。

メモリが足りなくなったときに現在使われていないプログラム(プロセス)を一時的にスワップファイルに書き出して消去し、占有していたメモリを開放することですね。

t2.microのサーバはメモリが1Gしかないため、すぐ落ちちゃうと。

swapファイルを作ることにした

512MBのスワップファイルを作成しました。

# dd if=/dev/zero of=/swapfile1 bs=1M count=512
512+0 records in
512+0 records out
536870912 bytes (537 MB) copied, 7.10056 s, 75.6 MB/s

スワップファイルが作成された事を確認します。

# ll /swapfile1
-rw-r--r-- 1 root root 536870912 Nov 11 23:49 /swapfile1

作成したスワップファイルのパーミッションを600に変更。

# chmod 600 /swapfile1
# ll /swapfile1
-rw------- 1 root root 536870912 Nov 11 23:49 /swapfile1

作成したスワップファイルをSwap領域用にフォーマット

# mkswap /swapfile1
Setting up swapspace version 1, size = 524284 KiB
no label, UUID=2b26981a-3731-41d5-bff5-5c51ce3be6ee

スワップファイルを有効化してSwap領域のサイズが増えたことを確認します。

# swapon -s
# swapon /swapfile1
# swapon -s
Filename                                Type            Size    Used    Priority
/swapfile1                              file    524284  0       -1
# free
       total       used       free     shared    buffers     cached
Mem:       1020188     910908     109280        140      14712     334288
-/+ buffers/cache:     561908     458280
Swap:       524284          0     524284

増えてますね。

さらにOS再起動した時用に/etc/fstabにも追加しておきます。

# cp -p /etc/fstab /etc/fstab.ORG
# cat /etc/fstab
#
LABEL=/     /           ext4    defaults,noatime  1   1
tmpfs       /dev/shm    tmpfs   defaults        0   0
devpts      /dev/pts    devpts  gid=5,mode=620  0   0
sysfs       /sys        sysfs   defaults        0   0
proc        /proc       proc    defaults        0   0
# echo "/swapfile1  swap        swap    defaults        0   0" >> /etc/fstab
# cat /etc/fstab
#
LABEL=/     /           ext4    defaults,noatime  1   1
tmpfs       /dev/shm    tmpfs   defaults        0   0
devpts      /dev/pts    devpts  gid=5,mode=620  0   0
sysfs       /sys        sysfs   defaults        0   0
proc        /proc       proc    defaults        0   0
/swapfile1  swap        swap    defaults        0   0

これでしばらく様子をみたいと思います。 また落ちるようならさらにswap領域を足すか、あんまりswapが多発してもディスクIO上がって遅くなるので、根本的にはサーバスペック上げるかですね。 PVが増えるとコストも増えるのは悩ましいです。