ISUCON7参加記

3回目のISUCON本選に学生枠で出場しました。

カッコイイ名札。

机が狭かったので目立たなかったですが、今年も参加してたわにさん。

一緒に出たメンバー

準備

予選が終わってから ISUCON7予選, ISUCON4決勝 をみんなで練習、あとは本番に向けてファイルシステム全体を git で管理するためのテンプレを作ったりしました。

練習は ISUCON5決勝 もやりたかったけどプロビジョニングがうまくできなくてパス、懇親会で動かせた人がいたと聞いたので是非公開してほしいです。

あとは、GitHubでやりとりする予定だったのでテンプレを import して当日用のリポジトリを作っておきました。 github.com

やったこと

  • / を git の管理下に沈める
  • 全員分のSSH鍵を入れる
  • fail2ban を殺して回る
  • 初期実装のままベンチ回してtopで負荷率見る
  • 実装言語をgolangに切り替えてベンチ回す
  • 2,3台目のサーバーにバイナリをコピーして systemctl restart するタスクを Makefile に書く
  • make しなおしてベンチ回す
  • @fono09 に入れてもらった kataribe を眺めたり、 mysqlslowdump を見るが WebSocket 以外のボトルネックがわからない
  • WebSocket まわりのコード読み始める
  • DBを調べてた @Goryudyuma と相談して room_name ごとに決まったサーバーで処理する方針に決める
  • なんかバグる
  • またバグる
  • 結局直らずどこが悪いかもわからなくなったのでほぼ初期実装にもどす
  • @Goryudyuma が書いてた big.Int 周りの最適化を手伝いながらやり直したら通った
  • 4台目のサーバーでもアプリケーションを動かし始める
  • pprof で見た感じ big.Int が遅すぎるのでいろいろ触ってみるがバグったり変化がなかったりで時間切れ

構成

3台動いていたアプリケーションサーバーを4台目にも入れて、それぞれ localhost のDBを見に行くようにしました。 すべてのサーバーが同じ構成で app と mysql が動いています。

ポータルに指定する先は1台目のサーバーのみチェックを入れていましたが、 負荷走行自体はすべてのサーバーに分散されるので、どれかひとつでもチェックがついていればいいという状況でした。 ただし、ルーム名で振り分けているので負荷が偏ってスコア誤差が±5,000点という超運任せ。

Redis や golang でオンメモリ化しようみたいな話も出ましたが、 トランザクションが面倒くさそうだったのと、CPUとメモリに余裕があったので諦めました。

感想

CPU・メモリ・ネットワークのどれも詰まっていないのに点数があがらない、 kataribe は通用しないし、スローログもトランザクションのコミットばっかりで問題がわからない、 big.Int が重そうみたいなのがわかってもどう対処すればいいかわからず手が付けられない、 みたいな状況がずっと続いていてかなり苦しいコンテストでした。 コードもあんまり書けなかったし…

優勝チームが対策していた big.Int のメモリアロケートのところとか、 見直せば pprof でちゃんと見えてたんだよなーってなるので悔しいです。

結果は全体12位で半分よりは上なので、まぁよかった(？) 学生枠では4位で、2,3位と僅差だったのでベンチマーカーにはもうちょっと空気読んでほしかったですね。(負け惜しみ)

就職するので学生としての出場はこれでラストですが、次があればまた出たいです。