ISUCON10予選に行ってきました。
毎度ながらとても楽しい8時間でした。時間が経つのが早い早い。
手元でのスコアは396(Python初期実装) -> 1601。それなりには増やせたものの、2歩ほど足りずに予選落ちとなりました。
例によって一人参加なので全部に手が回らないのは承知の上。
計測して遅い場所を解決するのを繰り返していきましたが、去年と同じく今年のベンチもスコアが安定しており、特に低スコアでもちゃんと差を出してくれていたのがとてもありがたかったです。
（とはいえ、最後までDBサーバーのCPU律速だったので、要らない修正もありましたが）
最後までDBのCPU使用率に悩まされたISUCONでしたが、Indexが思ったように効かなかったり、B-Treeの仕組みを把握しきれていない所がもろに出た感じですね。
定番の修正は以下のあたり
- Index付与
SELECT *修正- N+1クエリ削除
- Nginxの静的ファイルキャッシュ
最終構成
- isucon1: Web/AP
- isucon2: AP
- isucon3: DB
前回と同じく定番の構成でした。
終了後にrandomで出ていましたが、DBを2台構成にして垂直分散というのが目から鱗でしたね。
確かにJOINもないし2テーブル……最後までDB CPUに悩まされていたのもあって「その手があったかー」感がすごい。
nazotte検索をOpenCVへ
動作を見たところ凸包検索だったので外積で内包判定ができるパターン。
ゲーム作りがこんなところで役に立つとは思わなかった。
DBサーバーの負荷が高いのもあって、APサーバーにopencv-pythonを入れて判定するように変更。
low_pricedのオンメモリキャッシュ
あまり変動しないのでメモリ上にキャッシュしましたが、複数台構成になるとCSVインポート時に http://isucon2/api/update_cache 的なリクエストが必要になってちと微妙だった。
呼ばれる回数が多いので何か対策を取りたいところだが、redisキャッシュとかでも良かったか。
単純に自分以外のサーバーに/api/update_cache呼ぶようにしたらisucon1 -> isucon2 -> isucon1と無限ループして落ちたりも。
range_idのカラム追加
範囲検索やらAND条件だらけを=の検索にできるのでそれなりに効果はあった感じ。
PG側で何とかしましたが、chair.priceの条件違いで30分ぐらい嵌りました。
分かりやすい問題点なだけに他の人も似たことをやっている人が多かったようですね。
ORDER popularity, idをsort_keyにまとめる
DESC/ASCの混在もあってIndexが効かなかったのでORDER BY用にsort_keyを追加。
generated columnsを知らなかったので、こちらもPG側で力業。
出題側の想定回答の1つだったようで、たどり着けたのは良かったです。
MySQLの全文検索(FULLTEXT INDEX)による機能検索
[Stashed]
サンプルスクリプト作って MATCH(features) AGAINST ('+IHコンロ +フローリング' IN BOOLEAN MODE) などで検索できることは確認したものの、結局他のクエリが削り切れずにお蔵入り。
困ったところ1
ベンチマークがログ無しFailしてるけど、サーバー側ログにも何もない場合、原因追及が辛かったですね。
スコアは安定していたのですが、Portalの安定性も含めベンチマーカーからはもう少し情報が欲しかった所。
困ったところ2
Portalの不安定さや、直前のベンチマーカー全滅もあって、16:53の以下の発言を競技Portal自体の停止と勘違いしました。
あくまでleaderboardのみで、ベンチマーク自体は実行できたんですね……
16:53 根本対応を進めるため、 leaderboard を一瞬封鎖させてください
結局18:38の発言までベンチマーカーを動かさずに手元で開発していたので、ここのロスは痛かったです。
18:38 念の為書くとベンチはジョブリストから回せます
複数コミットあると前項の問題もあってベンチマーカーが落ちた場合の原因追及がつらい……
最後に
運営のみなさん、本当にありがとうございました＆お疲れ様でした。
今回はコードも読み切れる量でちょうどよく、オーソドックスなISUCONでありながらもあちこちに問題のある良問だったと思います。
社内ISUCONとかに使いやすい感じ。
今回は足りませんでしたが、延長戦含め、来年また頑張ります。
