Systems Performance: Enterprise and Cloudを読んでいく。
https://www.amazon.co.jp/Systems-Performance-Enterprise-Brendan-Gregg/dp/0133390098www.amazon.co.jp
日本語版しかないけれど、読み始めたら面白かったので、一字一句読み飛ばさず頭から読んでみるか!という気持ちになっている。(いつまで続くかは不明)
英語訳しながらだと全容が見えてこなくて辛いので、メモしていく。
1.1 Systems Perfomance
System performanceはシステムの全体(ハードもソフトも含む)を考慮する必要がある。 自分の扱うシステムの概要を書いて見ることは自分の理解のためになる。 図1は一般的なソフトウェアースタックを示したものである。
図1
1.2 Roles
システムパフォーマンスへの活動はさまざまな役割からなされるもので、業務の役割を超えて協力して考える必要がある。 パフォーマンスエンジニアは様々なチームと協力し、環境全体のパフォーマンスについて考える必要がある。 MySQLやJavaのようなアプリケーション特有のツールを使わないと部分的な確認しかできないものもある。
1.4 Perspectives
パフォーマンスについて考えるときには2つの視点がある。 - ワークロードから掘り下げていく視点 - デバイスの性能,リソースから積み上げていく視点
システム管理者はリソース視点で考えることが多く、アプリケーション開発者はワークロード視点で考えることが多い。
しかし、難しい問題に対しては両方の観点から考えることが有効。
1.5 Performance Is Challenging
主観的な事実を多く含み、システムは複雑で、かつ複数の問題を抱えているため、パフォーマンスについて考えることは難しい。
- Perfomance is Subjective
- このコードにはエラーがある/ないというように、白黒つけられないという意味でパフォーマンスは主観的である
- 主観性を客観的に捉えるためには明確なゴールを定める必要がある
- 例えば平均レスポンス時間や、レイテンシ範囲内でのリクエストの失敗率など
- Systems Are Complex
- There Can Be Multiple Performance Issues
- パフォーマンス上の問題を見つけることがゴールではない
- たいていパフォーマンス上の問題は複数見つかる
- パフォーマンスが良いとされている製品であっても、わかっているが修正されていないバグがあることは多い。
- これらの影響度を考え最も影響のあるものを発見する必要がある
- このためには問題の影響度を定量化する必要がある
1.6 Latency
- 操作の開始から完了までの時間
- ex) application request, database query, リンクをクリックしてからレンダリングされるまで
- レイテンシは有効な指標だが、これだけでは影響度を考えることは難しい
- レイテンシはシステムによっては平均しか得られなかったり、全く得られないこともある
- Dynamic Tracingと合わせることで、正確なレイテンシの分散がわかる
1.7 Dynamic Tracing
- Dynamic Tracingは全てのソフトウェアに組み込むことができる
- CPU命令を取得することで、実行中のソフトであっても統計情報を取ることが出きる
- Dtraceがプロダクションでも使えるツール
- Dtraceを使うことでuser/kernel空間の統計情報をリアルタイムに取得できる
1.9 Case Studies
- ケーススタディ
- Slow Disks
- Software Change