2013年9月17日火曜日

第6回ITインフラ勉強会@福岡の振り返り

第6回ITインフラ勉強会@福岡に参加してきました。
では、OS、DB、APとバラバラにチューニングしたので、何が効いてて
何が効いていないのかいまいち分からなかったので、
awsを使って確認してみました。
サーバは「「ISUCON 夏期講習」のサーバ環境のつくりかた
を参考にさくさくと作成。

まずはデフォルト状態でのスコアとCPU使用率を確認すると
CPU使用率:200〜300%

606 ticketsscore:811084

mysqlがかなりCPUを使っている。

で、勉強会で設定したmy.cnfを投入してベンチマークを実行すると、
CPU使用率85〜120%

1017 tickets
score:483295


となった。
デフォルトでmysqlがかなりCPUを使っていたので、
まずはmysqlのチューニングが効いてるのかな。
MySQLTunerに言われるがまま設定すると、この程度。

今日はここまで。

2013年9月8日日曜日

第6回ITインフラ勉強会@福岡に参加してきました。

第3回ISUCONに向けて、第6回ITインフラ勉強会に参加してきました。
開催内容は、ISUCON夏期講習のAMIで黙々とチューニング!

前回参加したチューニンガソンとの違いは、APの改修がOKなこと。
13:00から開始で、まずは自己紹介と前回のISUCONに参加された方から、
ISUCONの概要の説明の後、2チームに別れてチューニングを開始。

3人チームで分担を、OS、DB、APと分けて、黙々とチューニングしました。
私はAPはよく分からないので、詳しそうな方におまかせして^^;
DBのチューニング担当になりました。
MySQLは前回のチューニンガソンで1度触っただけですが、
その時の知識を思い出しながら、作業開始。

APはチケット販売サイトで、その性能を競います。
最初に素の状態でベンチマークを実行すると、以下のようになりました。


606 tickets
score:811084

ticketsの値は大きい方が、scoreの値は小さい方が高得点だそうです。

まずは、というかほとんどこれしかやってないんですが、
MySQLTunerを使って計測開始。これは前回のチューニンガソンで
仕入れた知識。
MySQLTunerに言われるがままに、cacheやbufferの値を設定。
それから、slowlogに出てくるqueryをexplainで確認して、
indexを貼ってみたけど、indexはよく理解できていないので、
本番までに勉強しておきます。

最終的に設定した値は、以下のとおり。

query_cache_size = 512M
query_cache_type = 1
query_cache_limit = 8M
table_cache = 256

join_buffer_size = 256
thread_cache_size = 256M

#slow_query_log
#long_query_time = 0.1

indexは忘れましたw

OS担当とAP担当の方も色々調整をされて、最終的なベンチマーク結果は、、、


1161 tickets
score:423350

約2倍のチケットをさばけるようになってました。
優勝チームは5500ticket  83474ticketだそうです。。。

今回は、OS、DB、APと思い思いに黙々とチューニングしたので、
どこの改修が効いたのか解らず・・・
本番では最初の方針と、途中経過を確認しながら進めた方が良さそう。

最後にチーム毎にチューニング内容を発表して、お開きとなりました。
仕事だとApache、Tomcatが多いので、
お進めのAPサーバなど、色々知らない事が聞けて参考になりました。

ISUCONに参加された方の話だと、インフラ周りのチューニングよりも
APのプログラム改修の方が効果が高いようです。
インフラ担当としてはAPを触らずにどこまでチューニング可能かが
興味のあるところです。

長い割に、内容が無いですがこんなところで。