Systems Performance 2章 読書メモ

Oct 29, 2016 ( May 1, 2017 更新 )

用語

  • IOPS
    • input output per second
  • Throughput
    • 特に通信において使われる
    • bytes per second など
    • DBではスループットは operation rate(operations per second or transactions per second) を指すことがある
  • Response time
  • Latency
    • ある操作が行われるまでの待ち時間を指す
    • いくつかの文脈中では、ある操作にかかる時間全体を指す。これは応答時間と等しい。2.3 Concepts で例を挙げる
  • 利用率
    • あるサービスが要求するリソースにおいて、利用率はあるリソースがどれくらいbusyであるのかの目安になる
  • Saturation
    • あるリソースにどのくらい仕事が積まれていて、サービスを提供できないかの程度
  • Bottoleneck
    • あるシステムの性能を制限してしまうリソース
  • Workload
    • システムに対するインプットか、あるいは受け入れられた仕事をworkloadという
    • DBにおいてはクエリやクライアントから送信されたコマンドを指す
  • Cache

モデル

以下は性能における基本的な原則をあらわすモデルである。

System under test

TODO: 図をAAで入れる

システムのインプットとアウトプットの間にpertubationsが入るテスト。

pertubations(interference,何か邪魔になるようなもの)が結果に影響するのは重要な点である。 それはシステムの別のタスクによるものだったり、ユーザの行動によるものだったりする。原因は明確ではないものだ。

クラウド上では調査が難しいことがある。それは、こういったpertubationsがシステムのハード部分からきている可能性があるからだ。そして、クラウドを使っているとハードの調査はできない。

他にも、モダンなシステムの環境では調査が難しい側面がある。複数のネットワークにまたがって何かのインプットがあったり、LBがいてさらにWebサーバ、DB、アプリケーションサーバ、ストレージサーバなどで1つのシステムが構成されていることがある。 こういった環境を統合して考えてみると、今まで見過ごしてきたpertubationsを突き止めることに役立つこともある。

Queueing System

Queueing system では、インプットがキューのタスクになり、あるサービスがキューからインプットを取り出して処理し、返答を返すまでが応答時間になる。

コンセプト

Latency

  • Webサービスの場合、 load time には以下が含まれている
    • DNS latency
    • TCP connection latency
    • TCP data transfer time

いろいろなメトリックがあるが、時間や決まったメトリックに揃えると考えやすい。 例えば、100 network I/O と 50 disk I/O という情報があったとする。この場合は network hops など、色々な要素が絡み合ってくるため何がよいかを考えるのは難しいが、network I/O でかかった時間が 100ms で disk I/O でかかった時間が 50ms というように変換できると、比べやすい。

Time Scales

table 2.2 の表に何の意味があるかわからなかった。

scaled to an imaginary system in which register access – 0.3 ns in real life takes one full second

ただの例えだと思うけど別に書かなくてもmsかかるポイントが重なったら応答時間が増えるのは理解できるので大丈夫って思った。

Trade-offs

  • CPUとメモリのトレードオフ
    • CPU使用率を抑えるためにメモリにキャッシュをのせる
    • メモリ使用率を抑えるためにCPUでデータを圧縮する
  • ファイルシステムのブロックサイズ
    • アプリケーションのI/Oサイズと近いブロックサイズだと、 random I/O workloads よりも性能が良くなる。また、アプリケーションが稼働している間、ファイルシステムのキャッシュを効果的に使うことができる（※なぜそうなるのか自分では理解できてない）
  • ネットワークのバッファサイズ
    • バッファサイズが小さいと、コネクションごとのオーバヘッドが小さくなる。これは、システムのスケールに役立つ
    • バッファサイズが大きいと、ネットワークのスループットをあげることができる

チューニング

  • レイヤによってチューニングのアプローチは異なる
  • アプリケーションレイヤだと、DBのクエリの調整（不必要なものを削除する、クエリを減らすなど）が効果的
    • slow queriesはCPU利用時間やファイルシステムやdisk I/Oから推測することができる

Point-in-time recommendations

  • 性能改善ポイントというのはその時代によって変わる。アーキテクチャの変化、ハードウェアの変化、ソフトウェアのアップグレードなど、環境が変化するためである

loadとarchitecture

  • 大量のloadが発生している場合に、アーキテクチャによっても何が問題なのかは変わってくる
  • 例えば、single thread applicationがCPUを使い切っていてbusyだが他のCPUが空いているような場合、 性能はsingle thread architectureによって制限がかかっていると言える
    • multi-thread applicationで利用可能なCPUをすべて使っている場合、マシンがさばききれる以上のloadが発生しているということになる

scalability

  • スループットをあげると、さばけるloadの量はある程度まで増え続ける
  • ただし、一定のところまでいくと、loadの量は下がってしまう
  • 例えば、重い計算処理をするアプリケーションの場合。loadが追加されるたびにthreadが追加される。CPU利用率が100％までいくと、性能が落ちる。これは、CPUのスケジューラのlatencyが増加しているからである。100％のCPU利用率で性能ピークまで達すると、スループットは低下する。これは、たくさんのスレッドが生成されているからである。大量のスレッドの生成は大量のコンテキストスイッチを発生させ、CPUを消費してしまい本当に行わなければいけない仕事ができなくなっていってしまう。
  • （図2.7より）loadがそこまで高くないのに、応答時間が長くなってしまうパターンはメモリが原因である可能性がある。ページやスワップをメインメモリ領域に移動させていることによって発生している。また、loadが高い場合に応答時間が長くなってしまうのはCPU起因である可能性がある。 ＊メモリ起因と同様に、loadがそこまで高くないのに応答時間が長くなってしまう例として、disk I/O起因があげられる。loadが増えると、たくさんのdisk I/O処理をキューイングするようになる。通常I/Oの応答時間が1msでも、loadが増えると10msになることもある。
  • アプリケーションがリソースを確保できないときに503を返すと、応答時間/loadの対応は線形となる。

known-unknowns

性能調査には以下のタイプがある:

  • known-knowns
    • あるメトリクスを調査しているとき、そのメトリクスが通常どのくらいの値であるか知っていること
  • known-unknowns
    • あるメトリクスを調査できる状況にあるものの、まだ調査していない場合。例えば、何がCPUをbusyにしているか調べられるがプロファイラを使って調査はしていない状況など
  • unknown-unknowns
    • 自分が知らないということをまだ知らない状態
    • 例えば、あるデバイスの干渉によりCPUを大量に消費するということを知らなくて、それを調査していないような状況

システムについて理解していくことで、unknown-unknownsをknown-unknownsにしていくことができる。

分析観点

性能分析には、2つの観点がある。

Workload分析

与えられたワークロード（アプリケーションレベルでの操作要求）に対しての応答時間（latency）と完了時のエラーを検証する。

Resource分析

CPU, メモリなどリソースの分析を行う。リソースが限界に達しそうか、限界に達するのはいつかを計測する。

指標として以下を計測する:

  • IOPS
  • throughput
  • 使用率
  • 飽和
Retrun to top