チームの作業の流れとしては下記のような流れでした。終了2時間前にスコアが急激に下がって焦る終了30分前からは反省を始める(残念なことにISUCONについてはほぼほぼ初心者の集まりだったためスコアを記録するなどしていないので、どういうスコア推移になったのかはわかりません。)スローガンを決める開始が延期したこともあって、チームでの作戦を午前中に立てていました。そこで決めたスローガンは「落ち着く」「いつも通りのことをする」「終了1時間前になったら変更をやめる」の3つでした。ISUCON用に準備していたわけでもないので、いつもやっていること以外はやっても不安定になるだけだろうということで、チャレンジはしないことにしました。レギュレーションと当日マニュアルをみんなで読むどこまで変えていいのか、最後の測定は再起動などどうなるのか、知っておかないとスコア残らないなんてことにもなるので、じっくり読みました。初期でちゃんとアプリケーションが動くかどうか確認するため、golangに切り替えてベンチマークを実行しました。最初の構成を確認して、appが2台とdbが1台であることを確認しました。1台だけcpu、メモリなどが違うなどの偏りはありませんでした。(@suzuki)gitにコードをpushし、makeコマンドのみで変更の反映ができるようにしました。(@ken39arg)alpとpt-query-digestで解析できるように、nginxのアクセスログとmysqlのslowlogを書き出す用に設定しました。結果から言うと、準備不足で最後までpt-query-digestの実行はできず、コードを見つつ、slowlogを目でざっと追ってindex張るなどしました。@suzuki)ユーザのアイコン画像がDBにBLOBで入っていたため、それを引き剥がしました。デフォルトユーザのアイコンをDBから引き出して、ファイルに保存しました。リクエストをそちらに流すようにしました。(@ken39arg)isubataではチャンネルのメッセージに対して、個々のユーザがどこまで読んでいるかを記録し、チャンネルの一覧部分で、未読件数をバッジで表示していました。この未読件数はチャンネルのループに対して、メッセージの集計クエリがループするというだいぶ重いものになっていました。isubataではメッセージの削除機能は存在していなかったため、メッセージの総数などはテーブルのカラムに追加して、ループクエリは削除しました。デフォルトのメッセージをカウントしてテーブルの更新をしていました。modifiedになるようにnginxで設定を行いました。いう、いかにもjson用の構造体など作っていますよ、みたいな名前のやつがいましたが、こいつは中でクエリを実行していて、ループクエリしていました。そこでぱぱっとクエリのループを消して、よしベンチ、と思ったらfail。メッセージに紐づくユーザを引いてくるという処理なのですが、元のクエリではuserのidは引いていなかったので、紐付けるidがないという状況でした。ken39argさんにも何がおかしいか見てもらうなど時間を使ってしまいました。@ken39arg)ここでボトルネックがDB+appサーバーのリソースに移っていたので、appを消し去り、DBのみとして、他2台でappの処理をすべて行うようにしました。受けることはせず、それぞれ保存して、nginxからtry_fileで存在しなかったら、もう片方にproxyするようにしました。ここでスコアは46万点を超えました。終了2時間前にスコアが急激に下がって焦る残念なことにここで私達の修正は終わりました。19:30を過ぎた頃だったと思います。(一応1日目の終了時刻は21:15ぐらい)再起動試験をしつつ、DBのチューニングにようやく取り掛かろうというところで、急にスコアが30万まで下がりました。原因がわからず、もう一度回すと20万、10万と下がっていきました。なんだ?と思っていたら、appサーバー2台がswapし始めていました。今まで変更のたびに再起動していましたが、DBのみの修正でapp再起動しななかったのですが、連続でベンチを実行することでメモリが太っていくことがわかったのです。これは推測でしかありませんが、アイコン画像のアップロードについて、ioutil.ReadAllしている箇所があり、これが良くなかったのかなと思っています。普段はReadAllなんてほぼほぼしないですが、ボトルネックにもなっていなかったし、画像データのsha1からファイル名を作っていたりと、修正が若干面倒だったので、放置していたのがよくなかった。(fujiwara組の記事にありますが、GOGCの設定でも充分に防げていたようです。)終了40分前からは反省を始める原因はわかったので、修正どうするという話になりました。数回のベンチマークであれば30万点程度までの落ち込みで済んでいたので、アプリの再起動だけして、放置しました。不安ではありましたが、無茶な変更してfailするよりはこのままにしようという決断をしました。nginxやmysqlのログも切らずにそのままにして放置。その間「これがよくなかったか。」「気づけたよなー」という話をずっとして過ごしていました。私もken39argさんも「落ち着く」ができておらず、アプリの修正でくだらないミスをしていたりして、時間の浪費があったので、これはなくしたかったという反省をしていました。まとめ結果として私達のチームは一日目予選一位で通過しました。本戦出場者決定のお知らせただ、全体としては5位であり、まだまだ改善できるポイントはチームの役割も含めてたくさんありました。決勝で勝つために予選での反省点を活かしていきます。最高に楽しいイベントを開催して頂いている運営の方々に感謝です。決勝もよろしくお願いいたします。予選1日目1位通過しましたISUCON6に参加してきました月別アーカイブはてなブログをはじめよう!mizkei11さんは、はてなブログを使っています。ブログを報告するスターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。