ある時から急に、t2.microインスタンスで稼働しているWordPressのサイトが「データベース接続確率エラー」で１週間に一度くらいの頻度で落ちるようになってしまいました。
いろいろ調査してみると、どうやらMySQLが落ちてしまっていることがわかりました。
こちらがその時のログです。
151010 03:21:04 mysqld_safe mysqld restarted
151010 3:21:04 [Note] /usr/libexec/mysql55/mysqld (mysqld 5.5.45) starting as process 4511 …
151010 3:21:04 [Note] Plugin ‘FEDERATED’ is disabled.
151010 3:21:04 InnoDB: The InnoDB memory heap is disabled
151010 3:21:04 InnoDB: Mutexes and rw_locks use GCC atomic builtins
151010 3:21:04 InnoDB: Compressed tables use zlib 1.2.8
151010 3:21:04 InnoDB: Using Linux native AIO
151010 3:21:04 InnoDB: Initializing buffer pool, size = 128.0M
InnoDB: mmap(137363456 bytes) failed; errno 12
151010 3:21:04 InnoDB: Completed initialization of buffer pool
151010 3:21:04 InnoDB: Fatal error: cannot allocate memory for the buffer pool
151010 3:21:04 [ERROR] Plugin ‘InnoDB’ init function returned error.
151010 3:21:04 [ERROR] Plugin ‘InnoDB’ registration as a STORAGE ENGINE failed.
151010 3:21:04 [ERROR] Unknown/unsupported storage engine: InnoDBB
151010 3:21:04 [ERROR] Aborting
151010 3:21:04 [Note] /usr/libexec/mysql55/mysqld: Shutdown complete
151010 03:21:04 mysqld_safe mysqld from pid file /var/run/mysqld/mysqld.pid ended
注目すべきは
151010 3:21:04 InnoDB: Initializing buffer pool, size = 128.0M
InnoDB: mmap(137363456 bytes) failed; errno 12
の部分です。
InnoDBのバッファプールのためのメモリ確保ができなかったようです。
ということはinnodb_buffer_pool_sizeを増やしてしまったらダメですね。
まずはInnoDBの初期設定値を確認してみます。
+———————————+———–+
| Variable_name | Value |
+———————————+———–+
| innodb_additional_mem_pool_size | 8388608 |
| innodb_buffer_pool_size | 134217728 |
| innodb_log_buffer_size | 8388608 |
| innodb_log_file_size | 5242880 |
| innodb_purge_batch_size | 20 |
+———————————+———–+
5 rows in set (0.00 sec)
当たり前ですが設定通りの内容になっています。
どうすればいいのか引き続き調査していると、t2.microインスタンスにswap領域がないということがわかりました。
こちらの記事で発見しました。
↓
MySQLが起動しない…in AWS – higehikiのブログ
海外のサイトでそのことに気づいた人がブログを書いていたようですね。
↓
Pro Web Development: Amazon EC2 Micro Instance Swap Space – Linux
ということでswap領域を作ってやることにします。
まずは状況を把握したいと思います。
MemTotal: 1019456 kB
MemFree: 733456 kB
MemAvailable: 922552 kB
[root@ip-172-30-0-167 ec2-user]# grep Swap /proc/meminfo
SwapCached: 0 kB
SwapTotal: 0 kB
SwapFree: 0 kB
[root@ip-172-30-0-167 ec2-user]# free
total used free shared buffers cached
Mem: 1019456 286032 733424 268 18112 166096
-/+ buffers/cache: 101824 917632
Swap: 0 0 0
やっぱりswap領域が完全にないみたいです…
スワップファイルを作成して、swap領域を拡張したいと思います。
まず、スワップファイルを作成します。
512+0 レコード入力
512+0 レコード出力
536870912 バイト (537 MB) コピーされました、 17.4791 秒、 30.7 MB/秒
続いて、swap領域を作成します。
スワップ空間バージョン1を設定します、サイズ = 524284 KiB
ラベルはありません, UUID=87bfeb87-9535-4cd6-82d2-39b3a0f61c6d
swap領域を有効にします。
[root@ip-172-30-0-167 ec2-user]# swapon /swapfile1
swapon: /swapfile1: 安全でない権限 0644 を持ちます。 0600 がお勧めです。
[root@ip-172-30-0-167 ec2-user]# chmod 600 /swapfile1
[root@ip-172-30-0-167 ec2-user]# swapon -s
Filename Type Size Used Priority
/swapfile1 file 524284 0 -1
スワップファイルを作成してswap領域を拡張したので、もう一度メモリの状況を見てみます。
total used free shared buffers cached
Mem: 1019456 825696 193760 268 18204 690820
-/+ buffers/cache: 116672 902784
Swap: 524284 0 524284
swap領域の自動マウントをさせるようにします。
#
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
リブートして設定を有効にします。
[root@ip-172-30-0-167 ec2-user]#
Broadcast message from ec2-user@ip-172-30-0-167
(/dev/pts/0) at 14:53 …
The system is going down for reboot NOW!
Connection to 54.178.166.120 closed by remote host.
Connection to 54.178.166.120 closed.
立ち上がったので、swapファイルとメモリの状況を確認してみると、
Filename Type Size Used Priority
/swapfile1 file 524284 0 -1
[ec2-user@ip-172-30-0-167 ~]$ free
total used free shared buffers cached
Mem: 1019456 206504 812952 268 12764 101576
-/+ buffers/cache: 92164 927292
Swap: 524284 0 524284
[ec2-user@ip-172-30-0-167 ~]$ grep Swap /proc/meminfo
SwapCached: 0 kB
SwapTotal: 524284 kB
SwapFree: 524284 kB
ちゃんとswap領域が確保されていることが確認できました。
MySQLを再起動してみます。
mysqld を停止中: [ OK ]
mysqld を起動中: [ OK ]
正常時のログです。
151021 11:15:53 mysqld_safe mysqld from pid file /var/run/mysqld/mysqld.pid ended
151021 11:16:51 mysqld_safe Starting mysqld daemon with databases from /var/lib/mysql
151021 11:16:51 [Note] /usr/libexec/mysql55/mysqld (mysqld 5.5.45) starting as process 2398 …
151021 11:16:51 [Note] Plugin ‘FEDERATED’ is disabled.
151021 11:16:51 InnoDB: The InnoDB memory heap is disabled
151021 11:16:51 InnoDB: Mutexes and rw_locks use GCC atomic builtins
151021 11:16:51 InnoDB: Compressed tables use zlib 1.2.8
151021 11:16:51 InnoDB: Using Linux native AIO
151021 11:16:51 InnoDB: Initializing buffer pool, size = 128.0M
151021 11:16:51 InnoDB: Completed initialization of buffer pool
151021 11:16:51 InnoDB: highest supported file format is Barracuda.
151021 11:16:51 InnoDB: Waiting for the background threads to start
151021 11:16:52 InnoDB: 5.5.45 started; log sequence number 2079806630
151021 11:16:52 [Note] Server hostname (bind-address): ‘0.0.0.0’; port: 3306
151021 11:16:52 [Note] – ‘0.0.0.0’ resolves to ‘0.0.0.0’;
151021 11:16:52 [Note] Server socket created on IP: ‘0.0.0.0’.
151021 11:16:52 [Note] Event Scheduler: Loaded 0 events
151021 11:16:52 [Note] /usr/libexec/mysql55/mysqld: ready for connections.
Version: ‘5.5.45’ socket: ‘/var/lib/mysql/mysql.sock’ port: 3306 MySQL Community Server (GPL)
今度はバッファプールのメモリも確保でき、正常に立ち上がったことが確認できました。
それ以降、以前は週一くらいの頻度で起きていた「データベース接続確率エラー」が発生しなくなりました。
本対策の効果が出ているのではないかと思います。
またなにか進展がありましたら、ここで報告したいと思います！
※ swap領域の拡張の手順についてはこちらを参考にさせていただきました。
↓
AWS Amazon Linux スワップファイル作成によりSwap領域のサイズを増やす – Qiita