Systems Performance 読んでいく (2章 その1)

Systems Performance: Enterprise and Cloudを読んでいく。
前回引き続き自分用メモ
２章は長かったので、3つくらいに分ける予定。その1は1~4節まで。

2 Methodology

パフォーマンスの問題に取り組むときに最初の挑戦は、どこから分析を始め、データを収集し、どのように分析するかを知ることである。

Methodologyは複雑なシステムにどのように取り組むかの手順を挙げてくれる。 また、これらは初心者にも熟達者にも詳細を取りこぼさないためのチェックリストとして役立つ

2.1 Terminology

• IOPS
  • 秒間のInput/Output操作量（転送量）
  • 特にdisk I/Oであれば、１秒あたりのread/writeの量
• Throughput
  • 単位時間あたりのタスクの実行率
• Response time
  • 操作が完了するまでの時間
  • これは結果が提供されるまでの時間(Service Time)を含む
• Latency
  • 操作が完了するまでの全体の時間
  • コンテキストによってはResponse timeと同じ
• Utilization
  • 利用率
  • 一定の時間に実際にどの程度そのリソースが利用されたかの割合
• Saturation
  • キューに蓄積されて実行できていないリソースの程度
• Bottleneck
  • システムのパフォーマンスを制限しているリソース
  • これを発見し取り除くことがパフォーマンス改善の基本
• Workload
  • システムへの入力、または割り振られたタスク
  • DBであればクライアントから送られたクエリやコマンド
• Cache
  • これ以降の遅いストレージの仕様を避けるために一部のデータをバッファリングするための領域
  • たいてい経済的な観点から容量が制限されている

2.2 Models

• System under Test (SUT)
• Queuing System

2.3 Concepts

2.3.1 Latency

• Latencyはひとつの操作を開始してから完了するまでの時間
• httpでgetリクエストする場合だとTCPコネクションを張って、データを転送し切るまでの時間
• さらに細かく見るとDNSレイテンシ(DNSが必要な状況なら) TCP handshakeレイテンシ, TCPデータ転送レイテンシに分解できる
• 時間を基準としているために様々な計算が可能
• 他のメトリクスを時間をベースに変換することで、比較しやすくすることができる
  • 100 network I/O or 50 disk I/O -> 時間を軸に変換することで比較可能

2.3.2 Time Scales

時間を軸にすることで数値的な比較が用意になった。　　 大体の規模感を把握するためにcpuの１サイクルを元にしたストレージへのアクセス時間を頭に入れておく

• 1cpu cycle 0.3ns
• L1 cache access 0.9ns
• L2 cache access 2.8ns
• L3 cache access 12.9ns
• Main memory access 120 ns
• SSD I/O 50-150μs
• ...
• ...

2.3.3 Trade-offs

• 一般的なトレードオフを知っておく
  • メモリとCPUのような2つの間のトレードオフ
  • "pick two": "Good　/　Fast　/　cheap"や、"Performance / On-Time / Inexpensive"から2つしか両立しない
• システムに変更を加える際はトレードオフの関係にあるものがないか考える

2.3.4

• チューニングできるレイヤは複数ある
  • Application
  • DB
  • System cals
  • File system
  • Storage

このときアプリケーションをチューニングすることでDBへのクエリをなくすことができれば効果はかなり大きい。

こういったことはアプリケーションの開発サイクルが早く、仕様上のテストはされてもパフォーマンス上のテストはされないことが原因であることが多い アプリケーションレベルのチューニングが効果的である一方で、OSのレベルでのチューニングができるとアプリケーションにも効果が期待できることも多く、さらに、OSレベルでみるとアプリケーションレベルの問題が簡単にわかる可能性も高い。

2.3.8 Scalability

• 負荷が上昇するシステムのパフォーマンスをそのシステムのスケーラビリティという
• 一般に負荷が大きくなる初期では線形にスループットが上昇するが、コンポーネントの使用率が100%に近づくに連れて、サチュレーションが起こり、スループットは減少しはじめる

2.3.9 Known-Unknowns

known-knowns, known-unknown, unknown-unknownsはパフォーマンスに重要。 パフォーマンスについて考えるときはこの順番で分解していくことになる。

• Known-knowns
  • すでに知っているもの
  • ある指標を確認する必要があると知っていて、普段の値も知っているもの
  • 例えばCPU利用率を確認するべきと知っていて、それが普段10%程度であると知っている 　

• Known-unknowns

  • 知らないことを知っているもの
  • メトリクスのとり方やサブシステムの存在は知っているが観察したことのないもの
  • 例えば何がCPUのりよう率を上げているか確認することはできるがしたことがない

• Unknown-unknowns

  • なにを知らないのかも知らないもの
  • 例えばデバイスの割り込みがCPUを激しく消費すると知らないので、それを計測しようと考えられない

パフォーマンスの分野は知れば知るほど知らないことが出てくる分野。 known-unknowonを確認することで、システムについて学べば学ぶほどunknown-unknownsに気づくことができるようになる。

2.3.11 Utilization

利用率はオペレーティングシステムの使用状況をあわらすためにしばしばつかわれる。 利用率には以下の２つがある。

• Time-based

  • 時間ベースの利用率は待ち行列理論によって正式に定義されている
  • U = B / T
    • U: utilization
    • B: total time the system was Busy
    • T: Time(observation period)
  • これはエレベータで表現すると、（人を運んでいる時間を実行中とする）以下のように言える
    • 100%: 常に誰かを運んで動き続けている状態
    • 0%: 常に待機中で誰も運んでいない
  • 時間ベースでの利用率100%は常に実行されていたというだけなので、それ以上の負荷を許容できることもある。

• Capacity-based

  • これはキャパシティプランニングのプロが用いる定義
  • コンポーネントの性能をどれだけ使っているかという利用率なので、100%の時はそれ以上の負荷は受けられない
  • エレベータで言うと以下のように言える
    • 100%: 定員上限いっぱい人がのっている
    • 0%: だれも載っていない

2.3.12 Saturation

• サチュレーションとはこれ以上処理ができない状態でそれ以上のリクエストを受けることである
• これはcapacity-basedな利用率が100%を超えるときに起こる
• time-basedな利用率ではキューイングが発生するため、100%でない時からサチュレーションが始まる

2.3.14 Caching

cacheは段階的に存在していて、多くの場合はメインメモリにデータをバッファリングすることをいうがコンテキストによって異なる

キャッシュのパフォーマンスを理解するための代表的なメトリクスはhit ratioとmiss rateがある

• hit ratio

  • 全体のアクセスのうちどのくらいのリクエストをキャッシュから取り出せたか
  • hit ratio = hits / total accesses
  • total accesses = hits + miss
  • hit ratioの上昇に対してパフォーマンスは線形ではなく指数関数的に良くなる
    • hit ratioが10%から11%の改善より90%から91%への改善のほうが大きい

• cache miss rate

  • 秒間にキャッシュミスした数
  • cache miss rateに比例してパフォーマンスが悪くなる
    • hit ratioが80%のAと90%のBシステムはBのほうがよく見える
    • しかし、cache miss rateでA:200/s, B:20/sであればBのほうが低速なデバイスへのアクセスが少なく処理も早いであろうことがわかる

キャッシュの状態を表す用語

• Cold : キャッシュがからか、本来欲しい物がなくhit ratioが0か0に近い状態
• Hot : 殆どのほしいデータがキャッシュに乗っている状態 (ex. hit ratioが99%以上)
• Warm : 有用なデータがキャッシュにある程度はある状態
• Warmth: どの程度キャッシュが温まっているかを表す

キャッシュを起動したり投入した段階ではColdな状態で徐々にWarmingされてキャッシュがうまく使えればHotになるという感じ

2.4 Perspectives

パフォーマンスには２つの観点がある workload analysisとresource analysisだ これらは分析する人もメトリクスもアプローチの仕方も違い、トップダウンとボトムアップとも言える

2.4.1 Resource Analysis

• システム管理者が主におこなう
• システムのリソースから考える
  • CPUs
  • memory
  • disks
  • network interfaces
  • busses
  • interconnections
• Performance issue investigations: 特定のリソースに関して責任を持つ
• Capacity planning: 新しいシステムのための情報や、既存のシステムのキャパシティを考える
• Metrics
  • IOPS
  • Throughput
  • Utilization
  • Saturation

2.4.2 Workload Analysis

• アプリケーション開発者が主に行う
• アプリケーションがどの程度レスポンスを返しているか計測する

• Target for workload analysis

  • Requests: ワークロードの適用
  • Latency: アプリケーションのレスポンスまでの時間
  • Completion: アプリケーションのエラー探し

• workload requestsを考えるとき、これらはシステムの属性を考えることも含む

  • DBのクライアントやテーブル名
  • これらを整理し、まとめることで不要なタスクを避けることができる
• LatencyはWorkload Analysisにおいて最も重要な指標
  • このコンテキストにおいてはrespose timeと同じものとして扱われる
• Metrics
  • Throoughput (Transactions per second)
  • Latency