このブログはawsのサーバを使っていて完全に自前で運営してるんですが、ブログ開始から3ヶ月、4回もmysqlが落ちてブログが使えない状態になってしまいました。これが無料ブログサイトとかだったら、サービス担当者が対応してくれるところですが、自前ブログだと自分で対応しないと永遠に落ちたままです。そこら辺が自前の難しいところですが、面白いところでもあります。
エラー画面
ちなみに落ちるとこんな画面が表示されます。
真っ白な画面にデータベース接続確立エラー
洒落っ気もなにもあったもんじゃない。
管理画面もこんな感じになります。
とりあえず復旧
とりあえず、復旧させるためには落ちた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
# 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が増えるとコストも増えるのは悩ましいです。
