Downloaded 15 times
![[社内勉強会]ELBとALBと数万スパイク負荷テスト](https://cdn.slidesharecdn.com/ss_thumbnails/elbalb-160822022623-thumbnail.jpg?width=640&height=640&fit=bounds)
![[D31] PostgreSQLでスケールアウト構成を構築しよう by Yugo Nagata](https://cdn.slidesharecdn.com/ss_thumbnails/d31postgresnagata-131128230735-phpapp01-thumbnail.jpg?width=640&height=640&fit=bounds)
システムパフォーマンス勉強会#1
- 1.
- 2. 注意 • このスライドは勉強会後に SlideShareにアップロードする予 定です • メーリングリストで告知予定
- 3. 今回の内容 詳解システム・パフォーマンス 1 章2 章 システムパフォーマンス分析に使う基礎的な概念の話 • 2章 メソドロジ • 用語 • モデル • コンセプト • 視点 • メソドロジ • モデリング • キャパシティプランニング • 統計 • モニタリング • ビジュアライゼーション
- 4. ■ 用語 • IOPS •1秒当たりの I/O オペレーション • スループット • 仕事が実行されるスピード • 特に通信ではデータ転送速度を表す • 応答時間 • オペレーションが完了するまでの時間 • ボトルネック • システムのパフォーマンスに限界を与えているリソース • キャッシュ • (物理キャッシュ) 限定された量のデータを重複して格納したりバッファリングしたりす ることができる高速記憶領域 • その他 • レイテンシ、使用率、飽和ついてはのちほど
- 5. メソドロジ(分析手法) • メソドロジは • 複雑なパフォーマンス問題を解決するための手法 •どこから手を付けるか？ • どのような手順を踏んだらよいか？ • 見落としをしないためのチェックリストとしても機能
- 6. テスト対象システムのモデル テスト対象システム 入力 (ワークロード) 得られる パフォーマンス 副次的影響 最も基本的なモデル • 副次的影響の特定は難しい • スケジュールされたシステムアクティビティ •システムの他のユーザ • 他のワークロード • 入力自体も複雑になってきている • データベースサーバ, アプリケーションサーバなどのネットワークで構成される場合がある
- 7.
- 8. ■コンセプト システムパフォーマンスの重要な概念 • レイテンシ • タイムスケール •トレードオフ • チューニング • 適切性の水準 • 基準時の推奨値 • 負荷かアーキテクチャか • スケーラビリティ • Known-Unknowns • パフォーマンス指標 • 使用率 • 飽和 • プロファイリング • キャッシング
- 9. レイテンシ(遅延) • オペレーションが実行されるまでの待ち時間 • 時間による指標 •さまざまな計算ができる • レイテンシが分かればスピードアップの上限がどれだけになるか予測できる • ことなる指標もレイテンシか時間に変換できれば比較可能 • ネットワークI/O と ディスク I/O のどちらを使った方がパフォーマンスが出るか? • 計測場所は様々→計測の対象で表現される • 例： • TCP 接続遅延 • TCPデータ転送遅延 • 動的トレーシングによって任意の場所で計測できるようになった 要求 完了 応答時間 レイテンシ オペレーション にかかった時間
- 10. タイムスケール 操作 レイテンシ 1CPUサイクル 0.3n秒 L1キャッシュアクセス 0.9 n秒 L2キャッシュアクセス 2.8 n秒 L3キャッシュアクセス 12.9 n秒 メインメモリアクセス 120 n秒 SSD I/O 50 ～ 150 μ秒 回転ディスク I/O 1 ~ 10 m秒 インターネット: SF ~ NW 40 m秒 TCPパケット再送 1 ~ 3 秒 VM リブート 4 秒 SCSI タイムアウト 30秒 時間についての直観が持て ると役に立つ 3.3GHz CPU を想定したタイムスケール
- 11. トレードオフ • パフォーマンスについてのトレードオフ • ２つを選ぶ必要がある •納期と低コストを選びがち • 後からパフォーマンス向上が不可能になることも • チューニングでもトレードオフがある • CPUとメモリ • キャッシュを有効利用してCPUの利用を減らす • データ圧縮にCPUを使いメモリの利用を抑える • ファイルシステムレコードサイズによるトレードオフ • アプリケーション I/O サイズに近づけるとキャッシュを有効利用できる • バックアップなどストリーミングのパフォーマンスが減少 パフォーマンス 納期 低コスト
- 12. チューニング • 表の上に行くほどチュー ニングは効果的 • ただし観察の場所として アプリケーションが最も 効果的とは限らない •遅いクエリは CPU 使用率 などを見た方が気づきやす い レイヤ チューニング対象の例 アプリケーション 実行されるデータベース クエリー データベース データベースのテーブル レイアウト、インデック ス、バッファリング システムコール メモリマップトファイル、 読み書き、同期/非同期 I/Oフラグ ファイルシステム レコードサイズ、キャッ シュサイズ、ファイルシ ステムのパラメタ ストレージ RAID レベル、ディスクの 数とタイプ、ストレージ のパラメタ
- 13. 適切性の水準 どのようなパフォーマンスが適切かの水準 • パフォーマンス要件は環境によってさまざま • 多くの場合はROI (Retrun on Investment ＝ 投資収益率) に依存
- 14. 基準時の推奨値 あるチューニングパラメタが有効なのは特定の基準時だけ • 環境のパフォーマンス特性は常に変化： • ユーザが増減した •新しいハードウェアを使いした • ソフトウェアを更新した • うまくパフォーマンスに働いたパラメタも「基準時の推奨値」 に過ぎない • とはいえ、チューニングパラメタと推奨値を記録しておくと後々役に 立つ
- 15. 負荷かアーキテクチャか • アーキテクチャに問題がなければ負荷が重すぎる場合がある • アーキテクチャに問題がある例 •シングルスレッドアプリケーション • 特定のCPUだけビジーで要求がキューイングされている場合 • これはアーキテクチャに問題がある • 負荷に問題がある例 • マルチスレッドアプリケーション • すべてのCPUがビジー状態になっている
- 16. スケーラビリティ • スケーラビリティとは、負荷に伴うパフォーマンスの変化 • 典型的なスケーラビリティだと •負荷が小さい間は線形スケーラビリティ • グラフの特定の位置(ニーポイント)にくると線形スケーラビリティか ら離れてしまう • リソースの競合による • 飽和点(saturation point)がニーポイントになる場合がある
- 17. Known-Unknowns パフォーマンスについては 「知れば知るほど、知らないことが増える」 • Known-Knowns • パフォーマンス指標をチェックしなければならないことを知っていて 現在の値も知っている状態 •Known-Unknowns • 指標をチェックしなければならないことはわかっているが、まだ観て いない状態 • Unknown-Unknown • パフォーマンスの指標をしらず、調査できていない状態
- 18. パフォーマンス指標 パフォーマンス指標 = 統計情報 •数値やグラフなどの形で得られる • 一般的な指標 • IOPS • スループット • 内容はコンテキスト依存 • 使用率 • レイテンシ • オーバーヘッド • 指標を収集し、格納するためにどこかでCPUサイクルを使ってしまう • 観察者効果 • 問題点 • ベンダが提供する指標が間違っている、誤ったものになる場合がある
- 19. 使用率 • 時間ベース • サーバまたはリソースがビジー状態だった時間の平均的な割合 •100%ビジーは 100% の能力とは異なる • 100%ビジーでもレスポンスを返せる場合もある • 能力ベース • 持っている能力を使っている割合 • この場合の 100% は要求を受け入れることができない
- 20. 飽和 (Saturation) • 処理できるよりもリソースに対する要求がどれくらい多いか •飽和は能力以上の要求を処理できなくなってキューイングが始 まったときにはじまる • 俗語：サチる
- 21. プロファイリング • 一定のインターバルでシステムの状態をサンプリングして、サ ンプルの集合を研究する • レイテンシなどに比べるとより統計的な値 •一定期間中に「 N %だけこの処理に使っていた」などの情報を得る • CPUなら次のような情報の統計を集めたりする • プログラムカウンタ • スタックバックトレース
- 22. キャッシング キャッシュはパフォーマンス向上のためによく使われる • キャッシングの指標 • キャッシュヒット率 •= ヒット / 全アクセス • キャッシュミス率 • 1秒間あたりのキャッシュミス
- 23. キャッシュ管理アルゴリズム • MRU (MostRecently Used) • キャッシュ保持ポリシー • もっとも最近に使ったオブジェクトを残す • LRU (Least Recently Used) • キャッシュ削除ポリシー • もっとも最近に使ったオブジェクトから削除する
- 24. パフォーマンス分析の視点 • リソース分析 • ボトムアップな視点の分析 •システムリソースの分析から始める • 作業： • パフォーマンス問題の調査 • キャパシティプランニング • 指標 • IOPS,スループット,使用率,飽和 • ワークロード分析 • トップダウンな視点の分析 • アプリケーションの解析から始める • 作業: • ワークロードの特性を把握する • アプリケーションの応答時間を調べる • エラーを探す • 指標 • スループット,レイテンシ アプリケーション システムライブラリ システムコール カーネル デバイス ワークロード
- 25. ■メソドロジ • 街灯のアンチメソッド • ランダム変更アンチメソッド •誰かほかの人を非難するアンチメソッド • その場限りのチェックリストメソッド • 問題の記述 • 診断サイクル • ツールメソッド • USEメソッド • ワークロードの特性の把握 • ドリルダウン分析 • レイテンシ分析 • メソッドR • イベントトレーシング • ベースライン統計 • パフォーマンスモニタリング • 静的パフォーマンスチューニング • キャッシュチューニング • マイクロベンチマーキング • キャパシティプランニング
- 26.
- 27. だれか他人のせいにするアンチメソッド 手順 1. 自分に責任のないシステムまたは環境のコンポーネントを見つけてくる 2. そのコンポーネントに問題があるという仮説を立てる 3.そのコンポーネントに対して責任を負うチームに問題を丸投げする 4. 仮説の誤りが証明されたらステップ１に戻る 防衛方法: 自分のせいにされた場合、告発者に対して「どのツールを実行し、出力を どのように解釈したか」を示してもらうとよい
- 28. アドホックチェックリストメソッド あらかじめ用意したチェックリストを逐一実行する手法 • 活用する場合は • 常にリストを最新の状態に保つ •問題の見分け方とフィックス方法を明確に記述する
- 29. 問題の記述 • サポートスタッフが最初に対処するときのルーチン作業 • 特に次のような事項について問題を記述する •パフォーマンスに問題があると思ったのはなぜか • このシステムは、良好なパフォーマンスで動いていたことがあったか • 最近の変更は何か。ソフトウェアか、ハードウェアか、負荷か • その問題はレイテンシか実行時間で表現できるか • この問題は他の人やアプリケーションに影響を及ぼしているか • 環境はどうなっているか
- 30. 科学的メソッド • 科学的説を立て、それを検証することでパフォーマンス問題について検討 する • 観察的な分析と、実験的な分析がある 手順 1.問題: パフォーマンス問題を設定する 2. 仮説: パフォーマンス問題の原因を仮定する 3. 予測: • (観察的) 何を観察できれば仮説が立証できるか予測する • (実験的) どのように環境を変更すれば仮説が立証できるか予測する 4. 検証: 観察、または実験を行う 5. 分析: 検証した結果を分析する
- 31. ツールメソッド ツールを使用した分析のアプローチ 手順 1. 利用できるパフォーマンスツールをリストアップする 2. 個々のツールについて、得られる役に立つ指標をリストアッ プする 3.個々の指標について、解釈のためのルールをリストアップす る
- 32. USEメソッド USE (Utilization, Saturation,Errors) • システムのボトルネックを見つけるために、パフォーマンス調 査の初期段階で使うべき手法 • すべてのリソースについて次の 3 つをチェックする • 使用率 • 飽和 • エラー
- 33. USEメソッドの手順 • はじめに調査対象にするリソー スをリストアップする • 各リソースに対して反復処理 •通常はエラーからチェック • エラー >> 使用率 > 飽和の順で 解釈しやすい 開始 リソースのリストアップ リソースの選択 エラー 使用率 飽和 他にリ ソース は？ 検出しことを精査 問題を 特定 終了 エラーがある 使用率が高い 飽和がある
- 34. ハードウェアのリソースリスト例 サーバハードウェアを想定 • CPU • コア,ハードウェアスレッド • メインメモリ • DRAM • ネットワークインターフェイス • イーサネットポート • ストレージデバイス • ディスク • コントローラ • ストレージ, ネットワーク • インターコネクト • CPU, メモリ, I/O リストに含めない方がよいもの • ハードウェアキャッシュ • 例: CPUキャッシュ • 使用率が高いほうがパフォーマ ンスがあがるため
- 35. ソフトウェアのリソースリスト例 • ミューテックスロック • 使用率→ロックされていた時間 • 飽和 →ロックを待ってキューイングされていたスレッド • スレッドプール • 使用率 →スレッドが要求を処理してビジー状態だった時間 • 飽和 →スレッドプールからのサービス待ちになっていた要求の数 • プロセス/スレッドの容量(特にプロセス/スレッド数の上限があるとき) • 使用率 →プロセス/スレッド数 • 飽和 →割り当てを待っているとき • エラー →割り当てが失敗したとき (cannot fork など) • ファイル記述子の容量 • プロセス/スレッドの容量と同様
- 36. USEの解釈方法 • 使用率 • 使用率100% → ボトルネックを起こしている兆候 • 使用率 60% 以下 → • 短期間の 100 %資料率が隠れているか可能性 • 一部のリソース(HDDなど) ではすでに遅れが発生している可能性 • 飽和 • 少しでも飽和があれば問題が起きている可能性がある • エラー • エラーカウンタが 0 以外なら精査すべき • 特にパフォーマンスが低いときにエラーが増える場合は要注意
- 37. ワークロードの特性の把握 不要な要求を排除できれば高パフォーマンスが得られる • 誰が負荷をかけているのか • なぜ負荷がかかっているのか •負荷の特徴は何か • 負荷は時系列的にどのように変化しているか を排除できるものは排除する
- 38. ドリルダウン分析 • システムパフォーマンス調査では３つのステージ • モニタリング •統計情報の記録、問題があるかもしれない場合にアラート • 特定 • ボトルネックの可能性があるリソース、領域を絞り込む • 分析 • 特定の領域を解析、問題を定量化
- 39. レイテンシ分析 ワークロードからコンポーネントを掘り下げる分析手法 • ワークロードから調査する • レイテンシに関係するコンポーネントを分解 •最もレイテンシの高いコンポーネントを見つける • 原因がわかるまで繰り返し MySQL クエリレイテンシ分析の例 • クエリレイテンシの問題があるか？ないか？ • 時間がかかっているのはCPU内か? CPU外か? • CPU外で使われた時間は何を待っていたか? • ファイルシステム I/O で時間がかかったのはディスクI/O か？ 競合 か？ • ディスクI/Oで時間がかかっているのはランダムシークか? データ転送時間か？
- 40. イベントトレーシング イベントを個別に検討して問題をみつける • よくトレーシングが使われるのは • ネットワークのトラブルシューティング⇒ tcpdump • システムコールレイヤ ⇒ strace • 次の情報を探す • 入力: イベント要求のすべての属性 • 時間: 開始時間, 終了時間, レイテンシ(両者の差) • 結果: エラーステータス, イベントの結果
- 41. 静的パフォーマンスチューニング • システムが休みに入っていて負荷がまったくかかっていないと きに実行できる • システムのすべてのコンポーネントを順に処理、チェック •コンポーネントに意味があるか • コンポーネントは想定されるワークロードに最も合う状態に自動的に 構成されるか • コンポーネントがエラーを起こし、最適ではない状態で動作している か
- 42. キャッシュチューニング • 一般的な戦略 • 処理が実行される場所に近いいいtでキャッシュしキャッシュヒットの オーバーヘッドを下げる •キャッシュが有効で、動作していることをチェックする • キャッシュヒット率、キャッシュミス率をチェックする • キャッシュサイズが動的に変わる場合、現在のサイズをチェックする • ワークロードに合わせてキャッシュをチューニングする • キャッシュに合わせてワークロードをチューニングする
- 43. ■モデリング アナリティカルモデリングはパフォーマンスの予測のために使う • 計測、シミュレーションのフィードバックを受けることができ る • 特にスケーラビリティ分析が重要 モデリングの例として: •Amdahlのスケーラビリティ法則を使ったモデリング • 待ち行列理論を使ったモデリング
- 44. Amdahl のスケーラビリティ法則 • システムのスケーラビリティをモデリングに使用する法則 •並列化によってスケーリングしないシリアルコンポーネントを 計算に入れる • 分析に使う場合は回帰分析で Amdahlパラメタ (α) を求める C(N) - N 1+𝛼(N−1) • C(N)→相対的な能力・容量 • N→ CPU数などスケーリングするパラメタ • α→どれくらいシリアルか • 0 の時は完全にパラレル • 1 の時は完全にシリアル
- 45.
- 46. キューイングシステムの分類 キューイングシステムは 3 つの要素で分類される •到着過程 – システムに要求が到着する間隔の性質 • サービス時間分布 – サービスを提供するためにかかる時間の性質 • サービスセンター数 – 1 か複数 サービス センター 入力 出力 キュー 応答時間
- 47. Kendallの記法 A/S/ｍ • A -到着過程 • S – サービス時間分布 • m – サービスセンター数 • M/M/1 • 到着 → マルコフ過程 • サービス時間 → マルコフ過程 • サービスセンタ数 → １ • M/G/1 • 到着 → マルコフ過程 • サービス時間 → 一般分布 • サービスセンタ数 → １
- 48. キャパシティプランニング 次を調べる • システムが負荷をどの程度うまく処理しているか • 負荷が増えた時にシステムがどれくらいスケーリングするか キャパシティプランニングの手法・作業： •リソースの限界の探求 • 要素分析 • スケーラビリティを向上させる方法
- 49. リソースの限界の探求 負荷のもとでボトルネックになるリソースを次の手順で探す 1. サーバーへの要求のペースを計測する 2. HW/SWリソースの使用状況を計測する 3. 使用しているリソースによってサーバ要求を表現する 4. 各リソースの既知の限界を使いきるサーバ要求の数を外挿法 で推定する
- 50. 要素分析 望ましいパフォーマンスを出すための要素の組み合わせを探す アプローチの例 1. すべての要素を最高値に設定してパフォーマンスを試す 2. 要素を一つずつ変更してパフォーマンスをテストする 3.計測にもとづき、要素ごとにパフォーマンスが落ちた割合と節約 できるコストを記録する 4. パフォーマンスの上限からスタートして、よそを取り除いていく 5. 計算によって得られた構成が必要なパフォーマンスを維持してい ることを確認する
- 51. スケーラビリティの向上 • 垂直スケーリング (スケールアップ) •より大規模なシステムを使う • マシンパワーに投資する • 水平スケーリング (スケールアウト) • マシンを増やして負荷を分散させる • ロードバランサ • シャーディング • DB のデータを分割して DB サーバを複数台にする
- 52. ■統計 • パフォーマンスの定量化 • 平均 •標準偏差、パーセンタイル、中央値 • 外れ値
- 53. パフォーマンスの定量化 • 観察による定量化 • 手順 •信頼性の高い指標を選ぶ • 問題を解決することによってパフォーマンスがどれだけ向上するか推計する • 実験による定量化 • 手順 • フィックスを行う • 信頼できる指標を使ってフィックスの前後を定量化する
- 54. 平均 • 算術平均 • 値の総和を値の個数で割ったもの •幾何平均 • すべての値をかけた席の n 乗根 • ネットワークのパフォーマンス分析に使う場合がある • ネットワークスタックの各レイヤのパフォーマンス向上は「相乗効果」で上がる • 調和平均 • 値の個数を値の逆数の総和で割ったもの • 速度の平均などに適している場合がる • 時間平均 • 時系列的にとった同じ指標に使用する • CPU使用率など • 減衰平均 • uptime などのロードアベレージに使われる
- 55. 標準偏差、パーセンタイル、中央値 • 標準偏差 • バラツキの度合いを示すもの •99 パーセンタイル • 分布の中で下から数えて 総数 × 99/100 番目の値が含まれる位置 • パフォーマンスがほとんどのユーザにとって教養範囲にあることを計 測するための手段として SLA にふくまれることもある • 中央値 • =50パーセンタイル
- 56. 外れ値 • 極端に大きいor小さい値が小数含まれる場合 • 正規分布の場合 •平均は少しずれる • 中央値はずれずらい
- 57. ■モニタリング • 時系列的なパターン • モニタリング製品 •ブート以降の集計
- 58. ■ビジュアライゼーション • 折れ線グラフ • 散布図 •ヒートマップ • 表面プロット • ビジュアライゼーションツール
- 59.