search

yuuki / isucon5-qualifier

はむちゃん
1 stars 0 forks source link

雑談所 #3

Open yuuki opened 9 years ago

yuuki commented 9 years ago

雑談用です。 :hamster:

yuuki commented 9 years ago

昨年の経験から、アプリケーションしかみてないとかOSレベルでしかみてない状態だと局所最適解におちいってしまうので、常に全員が全体を把握できている状態がよい。ISUCON 3か4の問題を１人で解いてみるのが重要そう。

失敗しそうなやつ

yuuki commented 9 years ago

パフォーマンスをみる

システムのパフォーマンス状況を把握するというのが多分もっとも重要。どれだけ実装が速くてもボトルネック以外を速くしても意味がない。 System Performance っていう本 (http://www.amazon.co.jp/dp/0133390098) にはシステムパフォーマンスの解析の方向性として、ワークロード解析とリソース解析の2軸があると書かれている。

screen shot 0027-08-30 at 2 16 56

ワークロード解析はアプリケーション的な視点での解析で、リソース解析はOS/ミドルウェア的な視点での解析だと思って良さそう。 アプリケーション的な最適化の余地がだいたい8割でOS/ミドルウェア的な最適化の余地は2割と、この本の著者がどこかで書いてた気がする。

リソース解析は結構得意で好きなんだけど、異常なパフォーマンス劣化を抑えることはできても、劇的にパフォーマンスがよくなったりはしない。 だいたいリソース解析から発見したボトルネックを潰すと劇的に改善できるイメージがある。

yuuki commented 9 years ago

ワークロード解析

リソース解析

top とか dstat とか。y_uuki的な理解だとシステムというのは細かくコンポーネントに分けると待ち行列が連続的に組み合わさったもの (参考: リトルの法則 https://ja.wikipedia.org/wiki/%E3%83%AA%E3%83%88%E3%83%AB%E3%81%AE%E6%B3%95%E5%89%87)。 例えば、リクエストを受け取ってレスポンスを返すまでを考えると、パケットを蓄積するキュー => TCPコネクションを受け付けるキュー（syn backlogと listen backlog) => Starletのワーカーキュー(キューじゃないけど) => MySQLのコネクションを受け付けるスレッド => MySQLのI/Oスレッド => ファイルシステム/ブロッグデバイスレイヤのI/Oキュー のようにいくつもの待ち行列がある。あとは全体でみてこれらの処理をスケジュールするCPUコアごとのランキューなど。 この中からtopとかdstatを使ってどの待ち行列がボトルネックを見つけるなのか見つける必要がある。 リソース解析視点でみてWebアプリケーションにとって理想的な状態はStarletのワーカー内のアプリケーションロジック部分のCPU時間がボトルネックであることになる。

ISUCONの場合でもやはりワークロード解析が支配的なイメージ。とはいえ、常にリソースがボトルネックになっていないかは見る必要がある。