# 性能測定道 実践編 Navigation: [[index]] | [[性能測定]] ## 概要 早水悠登(東京大学 喜連川研究室)による、日本PostgreSQLユーザ会(JPUG)しくみ+アプリケーション勉強会(2014年2月1日)での講演資料。全106スライド、前作「[[@2013__JPUG__性能測定道 事始め編|事始め編]]」の続編「実践編」にあたり、モデル化・計測・シミュレーションという性能測定の基本形を踏まえたうえで、CPUのメモリアクセスレイテンシ測定とストレージI/O性能モニタリングという2つの具体的な実践を、AWS EC2上でのライブデモとともに解説する。 > [!note] 取得経路について > SlideShare の該当ページはボット対策(Client Challenge)により PDF 原本の直接取得ができなかった。そのため CDN 上の個別スライド画像(image.slidesharecdn.com、638px幅 JPG、全106枚)を取得し、PDF原本の代わりに全ページ画像として `.raw/slides/seinou-sokuteidou-jissen-jpug2014/pages/` に保存した。PDF原本(`.raw/slides/<slug>/<slug>.pdf`)は存在しない。 ## 主要メッセージ - 性能測定の第一歩は「徹底的に調べ尽くす」ことである。プロセッサの動作原理・マイクロアーキテクチャ・動作周波数・キャッシュサイズ(TLB、L1〜L3)・インターコネクト・I/Oバスなど、測定前に知りうる範囲で性能モデルを構築して理解する(p.17-31)。 - 「実行時間とメモリアクセス回数は比例するとは限らない」。これがメモリアクセスレイテンシ測定の核心的な落とし穴であり、単純なforループでのメモリアクセス測定(`region[i]`を1e9×1MB回参照して実行時間を回数で割る)は誤りである(p.19-21, p.37-41)。 - 目的(メモリアクセス回数が実行時間に比例するようにメモリアクセスする)から、解決すべき問題(命令パイプライン・スーパースカラ実行、プリフェッチ、分岐予測ミス・ヒット)を導出し、それぞれを「ニート化」する(=意図的に無力化する)手法を1つずつ適用する(p.49-59)。 - 命令パイプラインとスーパースカラ実行のニート化: 1つ前の命令に必ずデータ依存する命令列(`movq (%%rax), %%rax` を連続発行しレジスタの読み出し結果を次の読み出しアドレスにする、いわゆるポインタチェイシング)によって命令間の並列実行を強制的に阻害する(p.52-53)。 - プリフェッチャのニート化: プリフェッチは順次アクセス・ストライドアクセスに対して効くため、ランダムアクセスにすることでプリフェッチを無効化できる(p.54-55)。 - 分岐予測器のニート化: 分岐予測器の挙動自体は制御が難しいため、そもそも分岐命令という「仕事を与えない」ことで対処する(p.56-59)。 - I/O性能測定は「I/O発行による負荷」と「挙動モニタリング」の組み合わせで行う。負荷生成にはmicbenchのioコマンドを使い、挙動モニタリングには標準のsysstat(mpstat/iostat)ではなく、出力の扱いにくさとリアルタイム性の欠如を解決する自作ツールPerfMongerを使う(p.94-105)。 ## 視覚的に重要な図表 **p.8 性能測定の3つの基本形** ![[_attachments/seinou-sokuteidou-jissen-jpug2014/page-008.jpg]] Modeling(モデル化)・Simulation(シミュレーション)・Measurement(計測)の三角形。前作「事始め編」の復習として提示され、本編ではこのうち計測(Measurement)の実践に焦点を当てる。 **p.23 NUMA環境のメモリアクセスレイテンシ実測グラフ** ![[_attachments/seinou-sokuteidou-jissen-jpug2014/page-023.jpg]] allocated memory sizeに対するaccess latencyの実測グラフ。node間のhop数(local DIMM・1 hop・2 hop)によってレイテンシが階層化される様子と、キャッシュ境界(16M付近)でのレイテンシの急上昇を示す。本編全体を貫く「メモリアクセスレイテンシを正確に測る」という目標を視覚的に提示する導入図。 **p.41 誤ったメモリアクセスレイテンシ測定コード** ![[_attachments/seinou-sokuteidou-jissen-jpug2014/page-041.jpg]] `region[i]`を単純にループ参照し、実行時間をアクセス回数で割るだけの素朴なCのコードに赤いバツ印を重ねた図。命令パイプライン・スーパースカラ実行・プリフェッチ・分岐予測によって「実行時間÷アクセス回数」が1回あたりのメモリアクセスレイテンシと一致しないことを視覚的に強調する。 **p.73 L1Dキャッシュの実測レイテンシとWikipedia理論値の比較** ![[_attachments/seinou-sokuteidou-jissen-jpug2014/page-073.jpg]] AWS EC2上でmicbench(`--rand --size 16K`)を実行し、L1Dキャッシュアクセスレイテンシ8.23クロック(誤差±5%)を計測。Wikipedia調べの理論値3クロックと比較し、実測値が理論値の約2.7倍であることを示す。 **p.85 主記憶アクセスレイテンシの実測結果** ![[_attachments/seinou-sokuteidou-jissen-jpug2014/page-085.jpg]] `--rand --size 256MB`実行時の主記憶アクセスレイテンシ567クロックを示すターミナル出力。L1(8.23クロック)→L2(24.6クロック)→L3(445クロック)→主記憶(567クロック)という段階的なレイテンシ増加を実測で裏付ける一連のデモの最終段階。 **p.100 sysstatの出力可読性の問題** ![[_attachments/seinou-sokuteidou-jissen-jpug2014/page-100.jpg]] iostat/mpstatの生出力に「Not readable!」の赤いバナーを重ねた図。sysstatの出力フォーマットが人間にとってもプログラムによる集計にとっても扱いにくいことを視覚的に指摘する。 **p.105 PerfMongerのリアルタイムダッシュボード** ![[_attachments/seinou-sokuteidou-jissen-jpug2014/page-105.jpg]] AWS EC2上でPerfMongerを実行し、ブラウザ上のダッシュボード(`http://54.201.1.14:20202/dashboard`)にCPU使用率をリアルタイム描画したスクリーンショット。sysstatの限界(可読性・リアルタイム性)を解決する自作ツールの実演。 ## 口頭説明・補足 - 講演冒頭、早水悠登は前日に博士論文の予備審査(いわゆる「呼び審査」)を通過したばかりであることを自己紹介の中で明かしている。「性能測定道」は前作「事始め編」がやや座学的な内容だったのに対し、本編「実践編」ではより込み入った実践的な話をする、と講演の位置づけを口頭で説明している。 - スライド上の8.23クロック(L1)・24.6クロック(L2)という数値について、講演者はAWS EC2が仮想マシン環境であるため、実際のCPUキャッシュレイテンシがそのまま測定できているわけではないと明言する。測定対象のインスタンスはSandy Bridge世代のCPUとして認識され、本来L1キャッシュへのアクセスは3クロックのはずが8クロック程度に見えており、この差異自体が「仮想マシンっぽさ」を示す兆候として捉えられる。物理マシン上で同じ測定プログラムを実行すると、文献値とほぼ一致する値が得られるという。 - 主記憶(256MB領域)のレイテンシがL3より遅い567クロックだったことについて、講演者はさらにアクセス領域を1GBまで広げると、レイテンシはさらに悪化すると口頭で補足している。理由は、OSがページ管理のために保持するページテーブルのlookupコストがアクセス領域の拡大に比例して積算されるためである。 - I/O性能測定のライブデモでは、AWS EC2にアタッチした2つのEBSボリューム(Provisioned IOPS、公称4000 IOPS)に対しmicbench ioで負荷をかけたところ、一方は1スレッドで70IOPS程度しか出なかった。原因をPerfMongerのモニタリングで確認したところ、もう一方の(既にデータが書き込まれている)ボリュームは1スレッドで約1400IOPS、8スレッドで公称値近くの約4000IOPSまで出ており、未書き込みのEBSボリュームに対してAmazon側のバックエンドがIOPSを制限している可能性を口頭で指摘している。 - PerfMongerのサブコマンドとして、`record`(JSON出力)、`start <command>`(指定コマンドの実行区間だけ測定して集計結果を表示)、`plot`(記録したJSONデータをグラフ化)、`bkko`(システムのI/Oスケジューラ設定等、あらゆる関連パラメータを一括取得する、俗語「ぶっこ抜く」に由来する名前)が口頭デモで紹介された。 ## Q&A - **Q: 測定プログラムが計測しているのは、命令フェッチの瞬間からメモリフェッチが完了するまでの時間か?** A: 命令パイプラインのうちデータフェッチの部分だけが実質的に時間を支配しており、命令フェッチやデコードの時間はネグリジブル(無視できるほど小さい)。実質的にはメモリへのアクセスが完了するまでの時間を測っていることになる。 - **Q: PerfMongerはLinuxカーネルにモジュールを追加する形で実装されているのか?** A: いいえ。Linuxの性能情報はprocファイルシステム以下にすべて公開されており、iostat等の既存ツールもそこを参照している。PerfMongerも同じ情報源(procファイルシステム)を見ているが、その集計方法を独自に整理してJSON形式で出力し、可読性を高めている点が異なるだけである。 ## 概念・実体への接続 - [[性能測定]] — 本講演が扱う中心概念。前作「事始め編」のモデル化・計測・シミュレーションの三角形を踏まえ、本編は計測(Measurement)の実践に焦点を当てる。 - [[早水悠登]] — 講演者。東京大学喜連川研究室、データベースシステム研究。micbench・PerfMongerの開発者。 - [[micbench]] — 本講演のデモで用いられたメモリ・ロック・I/Oマイクロベンチマークツールセット。 - [[PerfMonger]] — 本講演のデモで用いられた自作の性能モニタリング・可視化ツール。sysstatの限界を解決する目的で開発された。 - [[喜連川優]] — 講演者の指導教員。タイトルスライドで謝辞対象。 - [[@2013__JPUG__性能測定道 事始め編]] — 前作。性能測定の心と基本形(モデル化・計測・シミュレーション)を扱う。 ## 限界・不確実点 - SlideShare のボット対策により PDF 原本を取得できず、CDN上の638px幅JPG(全106枚)を代替の一次資料として用いた。原寸PDFに比べ解像度が低いため、細かい図表内の数値が一部読み取りにくい可能性がある。 - 音声/動画(https://www.youtube.com/watch?v=NpkHp05LyVU)の文字起こし(Whisper、Japanese)を反映済み。ただし機械文字起こしのため、専門用語の誤変換(「マイクロアーキテクチャ」→「マイクロアキテクチャー」、「命令」の言い回しゆれ等)が残っている可能性があり、数値・固有名は可能な限りスライド画像側を優先して裏取りした。 - 開催イベント名について、スライド説明文は「日本PostgreSQLユーザ会 第27回しくみ+アプリケーション勉強会」と記載するが、同ページに掲載されたイベントリンクは `shikumi28`(第28回を示唆)であり、回数表記に矛盾がある。前作「事始め編」も同じ「第27回」を名乗っており(2013年10月開催)、開催時期が4か月しか離れていない2つの講演が同一回数を名乗るのは不自然である。正確な回数は未確認。 - p.66・p.75・p.89・p.106等のライブデモ画面にはAWS EC2インスタンスへのSSH接続情報(ホスト名・ユーザ名・パスワード)が表示されているが、これは2014年開催当時限定の一時インスタンスであり、講演時点で既に「現在はアクセスできません」との注記がスライド上にある。デモ再現目的の参考情報であり、有効な認証情報ではない。 - p.66のスクリーンショット(MacBook Air本体の写真)はデモ環境のハードウェアを示すのみで、性能測定の主張とは直接関係しない。