カテゴリー: post

ISUCON12予選で0点だったので反省する

ブログを書くまでがISUCONです!ということで、点数も低くやれたことも少ないので恥ずかしいところも大きいですが書こうと思います。

概要

前提と行った準備

当日のタイムライン

前日

クーポンを適用する、private repoを作る、最初の一時間ですることを決める

9:55 予選問題の動画公開

10:00 問題公開

10:30 バックアップ完了

11:08 alp一回目回せる

この時点でのやることリスト

12:00 docker剥がした

dockerをisu1サーバで剥がしてdaemon化した。

14:00 バルクインサート失敗

ずっとSQliteからMySQL移行をしていた。一行ずつINSERTでは遅いことがわかったので、バルクインサートをしようとした。

エラーが出た。一行当たり16MBまでしか受け付けないらしい。対象の行は262MBくらいだったのでとりあえず50等分にしてみる

sedに慣れていなくて時間を溶かす

15:00 DB用サーバを立てる

16:30 LOAD DATA INFILEでMySQL移行に成功する(?)

以下のようなクエリで一番重い player_score の移行に成功した(多分)

アプリ側のコードもそれに合わせて書き換える

LOAD DATA INFILE '/var/lib/mysql-files/hoge.csv' INTO TABLE player_score FIELDS TERMINATED BY ',';

17:10 整合性チェックが通らない

Jul 23 08:11:50 ip-192-168-0-11 main[61353]: {"time":"2022-07-23T08:11:50.855873549Z","id":"","remote_ip":"127.0.0.1","host":"admin.t.isucon.dev","method":"GET","uri":"/api/admin/tenants/billing?before=21","user_agent":"isucandar","status":200,"error":"","latency":236423007211,"latency_human":"3m56.423007211s","bytes_in":0,"bytes_out":1503}

latencyがやばいのはわかる。原因はおそらくタイムアウトなのでどこかの処理が重いのだろうと思って billing を読む

データベースの初期化部分で init.sh がおかしいのかなと思って直したりした。

18:00 終了

結局整合性チェックを通せず、終了。得点は 0

反省ポイント

topの挙動が、mysqlが100%を超えている状態からmain(app)が支配的になるという2つのピークがあるように見える→DBを分離したらいいと思って複数台構成に取り掛かる

これはおそらく初期化でDBが重くなっている。また続くmainのピークも本当にdbの読み書きで重いのか(sqliteのせいなのか)はこの時点で不明。したがって、この考察が間違ってそうであることがわかる。複数台構成はマシン性能を上げるようなもので本質的な改善とは言えないのでここで何かやった気になるのはまずい。

ここではtopだけでは判断できないとしてalpで判断すべき。得点はalpを見てリクエスト数の変化を見たらどう上げたらいいか、点数の内訳がどのエンドポイントへのクエリなのかという構成が分かる。

大量の.dbファイルを発見してオイオイという気持ちになる。これは絶対MySQLに載せるやつやろと判断する

sqliteに対して直感で決めているのが良くない。計測で上のtopの挙動からも分かるようにDBやファイルアクセスが支配的とは言えないので後回しでもいい。

わかったこと