# 性能測定 ## 定義 性能測定とは、目の前にある計算機システムの姿を正確に捉えつづけるための技芸(art)である。Raj Jain の著書 "The Art of Computer Systems Performance Analysis" が指摘するように、性能評価は機械的に行えるものではなく、対象システムへの深い理解とモデル化・ワークロード・手法・ツールの慎重な選択を要する(Source: [[@2013__JPUG__性能測定道 事始め編]])。性能測定は単独の技術ではなく、モデル化(Modeling)・計測(Measurement)・シミュレーション(Simulation)という3つの基本形の組み合わせとして成立する。この3つは互いに検証(validate)し合う関係にあり、少なくとも2つ以上を使いこなすことが肝心とされる(Source: [[@2013__JPUG__性能測定道 事始め編]])。 - **モデル化**: 測定対象の内部動作原理を理解し、性能に影響する要素を選び出して数式化すること。科学的アプローチの原点であり、モデル化ができれば実際の計測前に性能を予測できる。適切なモデルは測定対象の理解そのものであり、モデル化が性能測定の全てを決めるといっても過言ではない。 - **計測**: モデル化の「しもべ」であり、モデルなき計測は意味を成さない。モデルが計測結果の正しさを裏付け、計測がモデルの正しさを確認するという相互検証の関係にある。 - **シミュレーション**: まだ存在しないハードウェアや未実装のソフトウェアの性能を、模した環境(専用ハードウェアやソフトウェアによるシミュレーション実行)で予測する手段。「もしもこうだったら?」という仮定を分析する技術であり、システムの一部を意図的に「端折る」行為でもあるため、計測・モデル化による正しさの確認が重要になる。 目的から性能測定の手法を導出する順序(測定するワークロード→測定するメトリック→メトリックのモデル化→測定環境→測定手段→計測実施→計測結果とモデルの照合)が推奨され、目的なきベンチマークツールの実行(「NG: ベンチマークツールを実行してみるだけ」)は戒められる(Source: [[@2013__JPUG__性能測定道 事始め編]])。 ## 横断的知見 - 「事始め編」が提示したモデル化・計測・シミュレーションの三角形のうち、続編「実践編」は計測(Measurement)を深掘りする。計測の核心は「測定したい量(メモリアクセス回数)と実測できる量(実行時間)を比例させる」ことにあり、CPUの命令パイプライン実行・スーパースカラ実行・プリフェッチ・分岐予測といった性能最適化機構がこの比例関係を崩すため、意図的にこれらを無力化する(ニート化する)コードを書く必要がある(Source: [[@2014__JPUG__性能測定道 実践編]])。これは「事始め編」で説いた「計測はモデル化のしもべ」というテーゼの具体例であり、CPU内部動作のモデルを理解して初めて正しい計測コードが書けることを示す。 - AWS EC2上でのライブ実測では、L1Dキャッシュのアクセスレイテンシが8.23クロック(Wikipedia調べの理論値3クロックの約2.7倍)、L2キャッシュが24.6クロック(理論値8クロックの約3倍)と、実測値が教科書的な理論値を一貫して上回った。講演者は口頭説明でこの差異の要因を明言しており、AWS EC2が仮想マシン環境であるためリアルなハードウェアのキャッシュレイテンシがそのまま見えているわけではないこと、同じ測定プログラムを物理マシン上で実行すると文献値とほぼ一致することを付言した。すなわち、モデル化された理論値と実測値の乖離それ自体が「対象システムが仮想化されているか」を判定するシグナルになりうるという、計測とモデル化の相互検証関係(事始め編の中心テーゼ)の具体的な応用例である(Source: [[@2014__JPUG__性能測定道 実践編]])。 - 主記憶アクセスのレイテンシは、アクセス領域のサイズが大きくなるほど悪化し続ける。これはOSがページ管理のために保持するページテーブルのlookupコストが、アクセス領域の拡大とともに積算されるためである(Source: [[@2014__JPUG__性能測定道 実践編]]、口頭説明)。キャッシュ階層の境界(L1/L2/L3/主記憶)だけでなく、ページテーブル管理という別のレイヤーの効果もメモリアクセスレイテンシの実測値に影響することを示す。 ## 未解決の問い - I/O REPLAY のようなワークロード再現によるシミュレーション手法は、HDD/SSD以外のモダンなストレージ(NVMe SSD、永続メモリ等)やネットワーク・GPU等の他リソースにどこまで一般化できるか。 - 未書き込みのEBSボリュームでIOPSが公称値より大幅に低くなる(講演デモでは1スレッド時に公称4000IOPSに対し実測70IOPS程度)現象について、講演者はAmazon側のバックエンドによる制御を推測として述べたのみで、確定的な原因(実際にそのような制御が存在するか、単なる初回アクセスのウォームアップ効果か)は未検証。 ## 関連 - [[@2013__JPUG__性能測定道 事始め編]] — 初出ソース。モデル化・計測・シミュレーションの三角形と、HDD/待ち行列/I/O REPLAYの実例 - [[@2014__JPUG__性能測定道 実践編]] — 続編ソース。CPUの性能最適化機構を無力化するメモリアクセスレイテンシ測定と、micbench・PerfMongerを用いたI/O性能測定の実践 - [[早水悠登]] — 講演者。micbench・PerfMongerの開発者 - [[喜連川優]] — 講演内で引用された OLTP モデル化論文の共著者 - [[micbench]] — 実践編で用いられたマイクロベンチマークツールセット - [[PerfMonger]] — 実践編で用いられた性能モニタリング・可視化ツール ## 出典 - [[@2013__JPUG__性能測定道 事始め編]] - [[@2014__JPUG__性能測定道 実践編]]