EC2でMySQLを走らせていて、何度かMySQLが落ちるという事態が発生しました。
だいたいの場合はテスト用・開発用なのでMySQL再起動で問題は無いわけですが、
場合によっては（主にお金の問題で…）microインスタンスを商用に使う場合もあります。
ということで原因を探りにログをあさってみたところ、どうやら、MySQL自体は生きているものの、InnoDBストレージエンジンがメモリ不足で落ちている模様です。
確かに、インストールしたままで動かしていたこともあり、また、microインスタンスの総メモリは613MBなので足りなくなってもおかしくはありません。
そんな時、「確かMySQLの想定メモリ使用量を計算する方法があったなあ」と思い出したので、そもそも計算上どうなのよ、というのを再確認しようと思い立った次第です。
公式リファレンスには
innodb_buffer_pool_size + key_buffer_size + max_connections * (sort_buffer_size + read_buffer_size + binlog_cache_size) + max_connections * 2MB
となっています。
http://dev.mysql.com/doc/refman/5.1/ja/innodb-configuration.html
この計算式でざっくりデフォルト値を計算すると、だいたい400MBくらいになります。
また、O’Reilly本の計算式に基づくと
http://rental.off-soft.net/323.html
ということで1GBくらい、という計算になっているようです。
＃そういえばこの本、手元にもあった（笑）。
そもそもmicroインスタンスにApacheなどWebサーバとして最小限のパッケージを入れて動かしている状態で、MySQLが動いていなくても既に300MBくらいは使用しています。たとえv5系リファレンスの計算通りだとしても足りないわけです。
じゃあmicroインスタンスでMySQLは使えないのか、というともちろんそんなことはなく、単純に max_connections の値を減らせば、メモリの使用量は減ります。どの計算式を使ったとしても、結局のところ全体の数値が押し上がっているのは、「* max_connections」の部分で100倍されているからです。
ということで、 /etc/my.cnf などに
max_connections=10
と追加することになります。
もちろん、レスポンスには影響が出ます。
これ以上のレスポンスを求めるのであればもっと大きいインスタンス使ってね、ということなわけですね。
＃そこんとこどうにかなりませんか、と問われてもさすがにどうにも…。
1 Comment