2013年9月25日水曜日
AWSのEC2のMicroインスタンスでMySQLが落ちる
vTigerCRMやWordpressに限らずな話なのですが、AWSのEC2でMySQL5.4を走らせていて、何度かMySQLが落ちるという事態が発生しました。
調べてみるとやはりInnoDBストレージエンジンがメモリ不足で落ちている模様です。
とりあえずMySQL再起動させても起動せず。
それならとApacheも再起動させると無事どちらとも起動。
たぶんこれApacheのプロセスがメモリ圧迫してんだなって雰囲気ですよね。
とりあえず何が起きているのかログを確認ということで、/var/log/messagesをひらいてみると、oom-killerが動いちゃってます。
実はApacheもMysqlもデフォルトの設定のまま使用してました。
EC2のmicroインスタンスの総メモリは613MB。
このサイズって、とりあえずWordpressとMySQLが動いた!やった!で構築後しばらくすると落ちるという程よいサイズな気もしますね。#被害妄想です。
今のところそんなにトラフィックはありませんのでmicroインスタンスで行く前提です。
さて、これどうすんだこれと、調べてみると山ほど情報が出てきますが、要は対応する内容としては二つ。
・ApacheとMySQLのメモリ使用量を下げる。
になります。
そんなわけでまずはApache。
まずは、Apacheの使用メモリ量を下げるために同時であがるプロセス数を落とすしかありません。
具体的な方法はこちらを参照してください。非常に良くまとまっています。勉強になりました。
結果、preforkの設定を以下へ変更です。
#計算結果を少しいじってしまいました。
MinSpareServers 3
MaxSpareServers 6
ServerLimit 140
MaxClients 140
MaxRequestsPerChild 1000
あと、余計なモジュールも読み込むのをやめついでにExpiresの設定を追加しています。
#これくらいは先にちゃんとやっておきなさいと突っ込まれそうですね。
次にMysqlです。
公式のリファレンス上の想定メモリ使用量の計算式から想定される使用量を計算すると、
innodb_buffer_pool_size + key_buffer_size + max_connections * (sort_buffer_size + read_buffer_size + binlog_cache_size) + max_connections * 2MB
この計算式でざっくりデフォルト値を計算すると、だいたい400MBくらいになります。
結局、max_connectionsを減らすしかないなということで、 /etc/my.cnf
max_connections=10
と追加しました。
現在、一つのMicroインスタンス上で、vTigerCRM5.4とvTigerCRM6のβ(ともにPHP5.3とMysql5.4)を稼動させていますが、これで何とか無事に動いてます。
ま、そんなわけで、vTigerCRMに限らずWordpressをEC2で動かすしているんだけどって方の参考になれば。
CRM TOUCHのサイトはこちら max_connections=10
と追加しました。
現在、一つのMicroインスタンス上で、vTigerCRM5.4とvTigerCRM6のβ(ともにPHP5.3とMysql5.4)を稼動させていますが、これで何とか無事に動いてます。
ま、そんなわけで、vTigerCRMに限らずWordpressをEC2で動かすしているんだけどって方の参考になれば。
vTigerCRMの日本語の情報に関してはこちら