Closed6
『絵で見てわかるシステムパフォーマンスの仕組み』を読む
もりたこれはなに
読むやつです。読むのはいか
たぶん4章くらいまで読んだら良い
気持ち
- 計算機の五つの要素みたいなのがわかってたら案外素朴に理解できるかもしれない
- 入力、出力、記憶、制御、演算
- chatGPTに聞いてなんとなく掴めた気がするんだけど、たぶんシステムのアーキテクチャの中にどんなものが含まれていて、その個別の実装をみたときにボトルネックだったり負荷がかかりそうなところを抑えれば分かるね
- つまり、アプリケーションサーバーとかロードバランサーとかデータベースサーバーとかがあって、それぞれどんなことをしてて、どういうボトルネックが存在するのか考えたらいける
- なんかもう満足した気もするな
- 調べるのは、
- webアプリケーションの典型的な構成例を知る
- 典型的な構成例をブレイクダウンし、個別の内部実装を理解した上で、どこを気にすべきなのか把握する
もりた1. パフォーマンスの基礎的な考え方
- この章の概要
- 重要なアルゴリズムの紹介とそのトレードオフ
- なぜアルゴリズムをやるのか？
- それってアプリケーションレイヤーの話でしかないよね？ なぜわざわざやるの？ パフォーマンスっていうとたくさんアクセスがきてとか悪いクエリを書いてしまってとかのことでしょう？
- その悪いクエリとかたくさんアクセスの裏にはアルゴリズムがある。基本的には全てアルゴリズムに適さない処理をさせているからパフォーマンスが悪化する、てことか？
- パフォーマンスを悪化させる要因は多分他にもあって、そこをまず地図として知りたいなあ
- それってアプリケーションレイヤーの話でしかないよね？ なぜわざわざやるの？ パフォーマンスっていうとたくさんアクセスがきてとか悪いクエリを書いてしまってとかのことでしょう？
もりた2. パフォーマンス分析の基礎
2.2 必要なパフォーマンス情報とは
- 挟み撃ちの原則
- 見たいリソースの前後も合わせてとる
- 時間の粒度
- 一時間に一度とかしかパフォーマンスとってないと平均になったものしか見れない
- まあクラウドサービス使ってたらこういうことは起きないね
- 一時間に一度とかしかパフォーマンスとってないと平均になったものしか見れない
- パフォーマンス情報の３種類
- 種類
- サマリ形式、イベント記録形式、スナップショット形式
- サマリ系式
- 一定期間の情報を合計、平均したもの。sarなど
- 概観を抑えやすいが、変動は見えない
- イベント記録形式
- 逐次のイベントを記録したもの。パケットキャプチャやシステムコールなど
- いつ何が起きていたのかわかるが、データが膨大になる
- スナップショット形式
- その瞬間の状況を記録する。psとかtopコマンド
- 定期的に取得することで効果を発揮する
- イベント記録みたいにするってことか
- 原因調査に向いているらしい。
- なぜ
- 感想
- これ、CloudWatchでどう確認するのか置き換えてみないとダメだな
- 種類
- 基本的な見方
- 三層サーバ構成だとして、
- どのサーバの負荷が高まっているか、スレッドが複数立っているのか、前後は立っているか、それとも暇にしてんのか
- Webサーバがたくさん負荷かかってて、APPサーバが暇だったら、Webサーバ内で問題が起きていると考えられる
- データの種類と分析のコツ
- まずサマリ形式でざっくりあたりをつけて、イベント形式やスナップショット形式で細かくみていく
2.3 パフォーマンス分析で重要な理論
- 待ち行列理論
- 処理にかかる時間は、待ち時間と処理時間のふたつ
- M/M/1とかって表現する
- 到着タイミング、処理時間、並列度
- 感想
- ちょっと何言ってんのかわからんな
- 平均待ち時間の計算
- 平均利用率：（処理時間＊処理件数）/単位時間
- 単位時間あたりで処理に使ってる割合か
- 待ち時間：平均利用率/（1-平均利用率）＊処理時間
- レスポンスタイム：待ち時間＋処理時間
- 平均利用率：（処理時間＊処理件数）/単位時間
- ここからわかること
- 利用率が上がると待ち時間は指数関数的に伸びていく
- 10→20と80→90では大違い
- この利用率ってなんだ？
- CPU利用率もこれ？ 使う側としてはめっちゃ待たされる？
- けどこれって平均していってるからだよね、つまりモニタリングが1分間隔でとられてて、その期間で80%とかなってたら、その期間で80%使われてるってだけ、ずっとまちがあるわけじゃない
- １時間ずっと80%なのと1分だけはちょっと意味合いが違いそう
- けど、それでも待ち時間は同じなのか。じゃあいいのか？
- バッチ処理は待ち行列自体は短い
- 一つのスレッドがずっと占有する
- CPUコアが２つあったら、片方だけずっと占有されて50%とかなる
- CPUコアが少ないと簡単に使用率は高まる
- 時間のかかる処理があればその処理やってる時間は100%だし
2.4 OSのコマンド
- 読み飛ばす
- ただ、ここで実際に取れてる指標がなんなのかは知っておきたい
- 紹介されたコマンドとそこから分かるものを調べるとか、CloudWatchへの変換をやるとか
- コマンドとわかるもの一覧
- sar
- サマリ形式
- CPUの使用率とアイドル、読み書きI/Oの量、メモリの概況
- プロセスごとの状況や瞬間的なパフォーマンストラブルとかはわからん
- vmstat
- サマリ形式
- 実行待ちの平均プロセス数。CPU使用率、スワップへのI/O、通常のI/O、コンテキストスイッチの回数など
- プロセスごとの状況や瞬間的なパフォーマンストラブルとかはわからん
- 短期で使ってもいいから、短くすれば見れることもある
- ps
- スナップショット形式
- その瞬間のプロセスとその状況、プロセス番号、CPU時間の累計
- 概況はわからん
- netstat
- サマリ形式
- ドライバレベルでのネットワークの問題。その瞬間のソケット、ルーティング情報、インタフェースごとの統計
- 通信のところはわからない
- iostat
- サマリ形式
- ディスクの使用率、レスポンスタイムや各種キュー長
- OSから見たディスクの稼働率であり、実際がどうなのかはわからん。レスポンスタイムで測るのが良い
- top
- スナップショット形式
- リアルタイムなOSの全体感。プロセスの情報を表示する。どんなプログラムやプロセスが動いているかわかる
- パケットダンプ（wireshark, tcpdumpなど）
- イベント記録
- どんな通信をしているのか詳細にわかる
- pstack
- スナップショット
- そのプログラム、プロセスがその瞬間にどんな処理をしているのかわかる
- スナップショットなので、ずっと同じ状態だったかとかはわからん
- システムコール（straceなど）
- イベント記録
- 特定プロセスがどんなシステムコールで待っているのか、OSの何の関数で時間を使っているのか
- アプリケーションプログラムが内部でどこに時間をかけているのかは分からない
- どのプロセスを疑うかあたりをつけてからやると良い
- まじでなんだ、OSの機能のどれを使ってるとかそういうレベルの話なんだ
- プロファイラ
- サマリ形式
- OSからみた特定プロセスに関して、どんな関数が何回呼ばれたか、どれくらい時間がかかっているか見える
- まとめ
- 見てるのは、
- CPUの使用率、アイドル、I/O、メモリ
- 実行待ちになっているプロセス
- ディスクアクセス、ネットワークなど
- つまり
- CPUがどれくらい忙しい/暇か、I/Oやメモリ
- ネットワークやIOの話
- プロセス単位の話
- 繰り返しちゃった
- つまり、うーん、コンピュータの五大要素である、制御、計算、記憶、入力、出力それぞれを考えてる
- あとプロセスの話
- まあ当たり前だけど内部構造がわかれば見るべきものもわかるね
- 見てるのは、
もりた第３章 実システムのパフォーマンス分析
3.1 Web/APサーバとJava/Cアプリ
- Webサーバ
- アクセスログ
- アプリケーションサーバー
- サマリ、スナップショット、イベント
- サマリはこの関数に統計的に時間がかかってるとか
- スナップショットはその瞬間動いているもの
- イベントはログだけど、ログ仕込まなくてもやってくれるやつもある、あればある
- 感想
- これなんだ？ アプリケーションサーバーで見るべきってなんだろ、負荷かかるのはアプリそのもの？の処理とか
- I/Oがあればそのレスポンスタイム？
- ここ分かったらそのI/O先が重いとか
- そもそも何を見たいわけ？ パフォーマンスて
- なにか重くて処理待ちになっちゃうよ〜てなるから、じゃあどこが重たいんだっけ？ て目星をつける、そのためには各断面？でレスポンスタイムを測ってそれぞれのリソースで重たいところとかをみる、リソースの目星がついたらプロセス見て、トレースみてどこで問題起きてるかとか？ どんどん小さくしていくとそのうちアルゴリズムが出てくるわけか
- 内部構造わかるといいな
- 接合点
- Webサーバからリクエストが投げられてたまるキュー
- DBMSへの接続プール情報
- サマリ、スナップショット、イベント
3.2 DBサーバ
- ありそうなのは、
- OSのCPU使用率、待ち時間処理時間、IO待ちがあるか、ネットワーク？ はないか
- IO待ちはディスクアクセスした時って感じ
- あとはtmp落ちとかを取れるなら取りたい、ここらへんは内部構造を知ってたらわかるやつ
- OSのCPU使用率、待ち時間処理時間、IO待ちがあるか、ネットワーク？ はないか
- ここら辺を知ったあとだとAWSのワークショップがだいぶわかる
3.3 ストレージのパフォーマンスの考え方
- キャッシュとディスクの話
- 最近はディスクIOとネットワークIOの境界があやふや
- クラウドだから
3.4 ネットワークパフォーマンス分析の考え方
- 考慮すること
- WindowサイズとACKというプロトコル的な考え方
- 物理的な距離の問題
- やりとりの回数がむしろ問題
- 間に入る中間機器がおおくて帯域を使いこなすのは難しい
3.5 原因調査
- 罠
- 被害者に注目しがちで、なぜ遅くなったのかが忘れられる
- サマリで絞り込んで被害者がわかったらイベントとかスナップショットで犯人探し
- 土台が揺らいでいることに気が付かない
- どのリソースが重たいか？ の次はどのレベルで重たいか
- CPUから重くなってるのかもしれんし
- これは特定のプロセスではなくて、OSのスローダウンを、知るとか？？？ よく分からん
- 負荷の変動に気が付かない
- どちらがボールを持っているか特定できない
- 連携して動くシステムで、どちらが重くなっているのか分かんない
- 因果関係を特定できない
- アーキテクチャを知ってないと分かんない
- 被害者に注目しがちで、なぜ遅くなったのかが忘れられる
- 大切にしたいと姿勢
- 断定しない
- コミュニケーション大切にする
- いろんなデータをみる
もりた第４章 パフォーマンスチューニング
まあ読んだら面白そうだけど、メトリクス？の話ではないので省略
もりた感想
- 良かった！
- 古いし、あたま動かさないといけないけど、抽象化されていないことを学べて良かった
このスクラップは3ヶ月前にクローズされました