ISUCON4 予選に参加されたみなさん、お疲れ様ですー。
"BIG丼" というチーム名で学生枠で参加していた @hktechno です。
チームメンバーは
の3人で参加しました。
全員筑波の入院生活民で、全員 SECCON CTF とかも出てるメンバーです。
全員 ISUCON 初挑戦です。準備も、何もしていませんでした。
全員 ISUCON 初挑戦です。準備も、何もしていませんでした。
まずは結果から...
僕達は、1日目の予選に参加したのですが、結果は以下のとおりです。
なんと、一般枠のチームを破り予選トップ！！
ISUCON という競技の性質上、そんなことがあっていいのか！
どうした現役インフラエンジニア！
と思うかもしれませんが、嘘を付いてもしょうがないので懺悔します。
正統派の方法で勝ち取った成績ではありません！！
1日目に提供されていたベンチマークプログラムにバグがあって、意図しない時間ベンチマークプログラムを流すことが出来る状態でした。
ベンチマークプログラムに与える workload のパラメーターの数値を極端に大きくすると、過負荷状態になって (load avg 100 とか) 本来想定していた時間に終了しないでベンチマークが流れてしまい、得点が上がるというバグを突いて驚異的な成績を叩き出しました。
これに気づいたのは、終了1時間ぐらい前でした。
少しつづ workload の数値を上げていくと、僅かながらベンチマークの数値が向上する現象を確認したので、頭打ちになる数値を確認していたのですが、上げれば上げるほど向上していくし、100を超えても上がり続けるんです...
そこで、あれ？なんか、おかしくね？なんかベンチマーク終わるの遅くね？って気づいたのですが、もしかしたらそういうゲームなのかもしれない... あるはずないだろ！
と思いながら少しづつ観察していたのですが、300 とか 400 に上げたあたりで5分以上ベンチマークにかかる状態になり...
流石におかしいと思って、残り15分でサポートチャットで、この現象が意図したものか、違反ではないかということを確認しました。
この時点では、workload の数がいくつかとか、どうやったら発生するかとかは隠したままです。
あえてギリギリに報告したわけではないですが、この時間ではこれに気づいた他のチームも、たぶん同じことは出来なかったでしょう。
でも、既にこの問題に気づいていた他のチームもあったみたいです。
結果的に、今のところは最終的な結果は認められているようですが、2日目にはこの問題の修正が入ったようです。
出場枠の扱いについてもいろいろ変更があるようです。
詳しくは、運営の皆さんからのアナウンスを待ちましょう。
僕達の本戦出場も、AMI 検査もありますし、結果が正当なものではないのでどうなるかはわかりません。
いろいろあると思いますが、こういう事態はコンテストにはつきものですね...
それがひとつの醍醐味でもありますし？
それと、全員 SECCON CTF の全国大会出場メンバーだからって、別に benchmarker を逆アセかけて解読したりはしてないですからね...
運営の皆さんは、お疲れ様でした。
正統派な方法でどこまでやったか...
チートの話を聞いてもしょうがないので、少しちゃんとした話もしましょう。
僕達のチームの最終的な提出結果は --workload=350 で
tag:benchmarker type:score success:401684 fail:166 score:86974
でした。
--workload=16 ぐらいにすると、大体 20000 点台でしたね。
なので、本来は全然本戦出場枠に届いていないです。
基本的には、DB に Index をつけて、MySQL と Unicorn を TCP ではなく Unix Domain Socket を使うようにして、static なファイルを nginx から配信するようにして、TCP TIME_WAIT 対策をして... ぐらいで昼前に 20000 点超えた気がします。
午後からは、Ruby 2.1 にしてみたり、DB のスキーマとコードに手を入れていたのですが、どちらも完全に逆効果だったので、元に戻しました。
/ が、ほぼ静的なページなのでどうにかしようと思ってましたが、うまくいかなさそうなのでやめました。
なので、ほぼコードには手に入れてない状態です。
チートな方法では、ファイルディスクリプタの制限にかかり始めたので、limits.conf や ulimit をいじって上げたりもしました。
ISUCON は、コードから手を入れるのは沼にはまっていくのはわかっていたので、午前はいじらずに行けるところまでいって調子良かったのですが、午後からつまりましたね...
結果的に、午後からはほぼスコアが向上しなかったです。
>> 追記
その後、延長戦を勝手にやっていたのですが Sinatra が development モードで動いてる事がわかり、production モードで動くように設定したら一気にスコアが向上しました。
さらに、MySQL のパラメータをちょこっとチューニングしたら、38000 ぐらいまでスコアが上がりました。
うまく改善した効果が出なかったのはこんなボトルネックがあったとは...
これはひどい。
>> 追記ここまで
敗因は、何が原因で詰まってるかを解析する方法がちゃんと用意出来ていなかったので、完全に手探りだったところですかね...
次出るときは、その辺りをちゃんと固めたいと思います。
まとめ
なにがさすがだ。実際はゴミクズ以下だった僕を慰めてくれ。
