# Brendan Gregg システムパフォーマンス分野の第一人者。DTrace・flame graph・BPF パフォーマンスツール群の作者として知られる。2017 年当時 Netflix のパフォーマンスエンジニア、その後 Intel でシステムパフォーマンスアーキテクト。 ## 主な貢献 - **Flame Graph(フレームグラフ)**: CPU プロファイルを可視化する手法。業界標準ツールになった。横幅が消費CPU時間、縦方向がコードパスを表し、CPUの問題だけでなくロック競合やメモリ問題、ネットワーク設定ミスもCPUに残された痕跡から発見できる([[フレームグラフ]]、Source: [[@2023__OReillyJapan__詳解 システム・パフォーマンス 第2版 - Chapter 1 イントロダクション]] §1.7.2)。 - **DTrace / dtrace**: Solaris 由来のダイナミックトレーシングフレームワーク。macOS・FreeBSD にも移植。 - **BPF Performance Tools**: Linux BPF(eBPF)を使ったパフォーマンス観測ツール群の設計・実装。 - **「CPU Utilization is Wrong」(2017)**: %CPU の誤解を IPC で正す古典的エッセイ([[@2017__brendangregg.com__CPU Utilization is Wrong]])。 - **USEメソッド(Utilization, Saturation, Errors)**: システムリソース(CPU・メモリ・ディスク・ネットワーク・GPUなど)の状態を使用率・飽和度・エラーの3観点から体系的に観測するフレームワーク。Netflixでの実践を通じて提唱し、Flame Graphやebpfなどの性能可視化技術の普及にも貢献した。AI処理のGPU性能分析でも、GPU使用率が高いだけでは性能が最善とはいえない(PCIeエラーやメモリ割り当て待ちの見落とし)ことを見抜くために引用される。(Source: [[@2026__技術評論社__実践的パフォーマンスエンジニアリングによるAI高速化 - Chapter 1 パフォーマンスエンジニアリング概論]]) - **可観測性ツールの分類法**: 可観測性ツールを「システム全体/プロセスごと」×「固定カウンタ/イベントベース」の2軸4象限、および静的パフォーマンスツール/クライシスツールに整理する分類法を『詳解 システム・パフォーマンス 第2版』4章で提示した。トレースポイント・kprobe・uprobe・USDT・PMC といった情報ソースをオーバーヘッド実測値(kprobe 76ns〜uretprobe 1,931ns)付きで体系的に説明している。(Source: [[@2023__OReillyJapan__詳解 システム・パフォーマンス 第2版 - Chapter 4 可観測性ツール]]) - **KPTIの性能影響を本番ワークロードで定量評価**: 著者はメルトダウン対策のKPTIパッチが、Netflixのクラウド本番ワークロードで0.1%から6%の性能低下を招くと評価した(数値はワークロードのシステムコール率に依存)。ヒュージページの利用やトレーシングツールによるシステムコール率分析でコストを緩和できるとする。(Source: [[@2023__OReillyJapan__詳解 システム・パフォーマンス 第2版 - Chapter 3 オペレーティングシステム]] §3.4.3) - **メソドロジの体系化**: 『詳解 システム・パフォーマンス 第2版』第2章では、[[USE メソッド]]の詳細(街灯のアンチメソッド等との対比、指標の解釈方法)に加え、ドリルダウン分析・レイテンシ分析・ワークロードの特性の把握・静的パフォーマンスチューニング・パフォーマンスマントラなど20種類以上のメソドロジを整理・命名し、多くを自ら考案または命名した(街灯のアンチメソッド、ランダム変更アンチメソッド等)。レイテンシのヒートマップ可視化も著者が2008年に Sun Microsystems の ZFS ストレージアプライアンス分析で初めて使い、Grafana 等に普及させた手法である。(Source: [[@2023__OReillyJapan__詳解 システム・パフォーマンス 第2版 - Chapter 2 メソドロジ]] §2.5, §2.10.3) - **Linux 60秒パフォーマンス分析チェックリスト**: あらゆるパフォーマンス障害の調査で最初の60秒に実行できる、uptime・vmstat・mpstat・pidstat・iostat・free・sar・topなど10個の伝統的CLIツールをまとめたチェックリスト。2015年のNetflix Tech Blog記事「Linux Performance Analysis in 60,000 Milliseconds」が原型になっている。(Source: [[@2023__OReillyJapan__詳解 システム・パフォーマンス 第2版 - Chapter 1 イントロダクション]] §1.10.1) - **可観測性ツールと実験ツールの区別**: カウンタ・プロファイリング・トレーシングを使う可観測性ツールはシステムの状態を変えないが、ベンチマーキングツールなどの実験ツールはワークロード実験によってシステムの状態を変えてしまうと明確に線引きし、本番環境ではまず可観測性ツールを優先すべきだと説く([[オブザーバビリティ]]、Source: [[@2023__OReillyJapan__詳解 システム・パフォーマンス 第2版 - Chapter 1 イントロダクション]] §1.7, §1.8)。2017年当時は[[Netflix]]のパフォーマンスエンジニアとして、クラウドパフォーマンスチームで誰でも使えるパフォーマンスツール作りに従事していた。 - **wss(8)によるワーキングセットサイズ推定**: PTE(ページテーブルエントリ)のアクセス済みビットをリセットして一定時間後に再チェックする実験的な手法で、ワーキングセットサイズ(WSS)を推定するツールwss(8)を自ら作成した。WSSは可観測性ツールが通常表示しないメモリ使用の重要指標であり、注意書き付きの実験的ツールでも紹介する価値があるとしている。(Source: [[@2023__OReillyJapan__詳解 システム・パフォーマンス 第2版 - Chapter 7 メモリ]] §7.5.12) - **メモリ分析メソドロジの提示**: 『詳解 システム・パフォーマンス 第2版』7章では、メモリ問題の解決に「パフォーマンスモニタリング→USEメソッド→使用形態の特性の把握」の順序を推奨し、メモリリークと正常なメモリ増大を取り違えないための切り分け方(構成・アロケータ挙動の確認を先行させる)を示した。Linuxの利用可能メモリ管理(フリーリスト→ページキャッシュ破棄/スワッピング→リーピング→OOMキラー)の全体像を図解した。(Source: [[@2023__OReillyJapan__詳解 システム・パフォーマンス 第2版 - Chapter 7 メモリ]] §7.4, §7.3.2.1) - **アプリケーション分析ツール群の作者**: off-CPU分析というメソドロジとそれを実行するツールを2005年に作り、BCC版offcputime(8)を2016年1月13日、profile(8)を2016年7月15日(サッシャ・ゴールドシュタイン、アンドリュー・バーチャル、エフゲニー・ヴェレシチャーギン、テン・キンのコードがもとになる)、execsnoop(8)の最初のバージョンを2004年3月24日(Linux BCC版は2016年2月7日、bpftrace版は2017年11月15日)に作った。libpthreadのpthread_mutex_lock()等をインストルメンテーションするbpftraceツールpmlock(8)・pmheld(8)、pthread_create()経由のスレッド作成をトレースするthreadsnoop(8)、JavaプロセスからPerf Map Agentの補助シンボルをダンプする自動化ツールjmapsも自ら開発した。(Source: [[@2023__OReillyJapan__詳解 システム・パフォーマンス 第2版 - Chapter 5 アプリケーション]] §5.4.2, §5.5.2〜§5.5.3, §5.5.5, §5.5.7.1, §5.5.7.3, §5.6.1.2) - **アプリケーション性能分析の8メソドロジと9状態スレッドモデル**: 『詳解 システム・パフォーマンス 第2版』5章では、CPUプロファイリング・off-CPU分析・システムコール分析・USEメソッド・スレッドの状態の分析・ロック分析・静的パフォーマンスチューニング・分散トレーシングの8メソドロジを整理した。とりわけスレッドの状態の分析は著者が「すべてのパフォーマンス障害で最初に使う」と位置づけるメソドロジで、on-CPU/off-CPUの2状態を拡張した9状態モデル(ユーザー・カーネル・実行可能・スワッピング・ディスクI/O・ネットワークI/O・スリープ・ロック・アイドル)を提示し、Solarisのマイクロステートアカウンティングを出発点に開発したとしている。([[スレッド状態分析]]、Source: [[@2023__OReillyJapan__詳解 システム・パフォーマンス 第2版 - Chapter 5 アプリケーション]] §5.4.5〜§5.4.5.1) - **CPU可視化ツール群(showboost・pmcarch・tlbstat・FlameScope)の作者**: `msr-cloud-tools`リポジトリのshowboost(8)(“show turbo boost”、MSRを読んでCPUクロックスピードとターボブースト状況を表示。Netflixでturbostat(8)が使えるようになる前に自作)、`pmc-cloud-tools`リポジトリのpmcarch(8)(Intel architectural set PMCベースでIPC・分岐予測ミス率・LLCヒット率を表示)・tlbstat(8)(TLBウォークの統計)、Netflix開発のFlameScope(秒未満オフセットヒートマップとフレームグラフを結合し、通常のプロファイルでは埋もれる短時間の摂動を発見するツール)の作者である。これらはAWS EC2クラウド環境で動作するようプロセッサ固有PMCを使っているため他環境では動作しない場合があるが、著者は「動かなくても便利なPMCの例を教えてくれる」としている。(Source: [[@2023__OReillyJapan__詳解 システム・パフォーマンス 第2版 - Chapter 6 CPU]] §6.6.10〜§6.6.12, §6.7.4) - **CPUフレームグラフの生成パイプラインと解釈手順の体系化**: 『詳解 システム・パフォーマンス 第2版』6章では、perf(1)/BPFベースのprofile(8)からフレームグラフを生成するパイプライン(Linux 2.6〜4.8のperf経由と4.9以降のBPF直接計算)を図解し、フレームグラフの色相・彩度・背景色の設計原理と、「高原を探す→階層構造を理解する→分散した共通パターンを探す」という3ステップの解釈手順を明文化した([[フレームグラフ]]、Source: [[@2023__OReillyJapan__詳解 システム・パフォーマンス 第2版 - Chapter 6 CPU]] §6.5.4.1, §6.5.4.2, §6.7.3)。 - **runqlat(8)/runqlen(8)の作者**: Solaris用に自作したdispqlat.d/dispqlen.dツール(ディスパッチャキューレイテンシはSolaris用語でランキューレイテンシと同義)をもとに、runqlat(8)は2016年2月7日にBCC版・2018年9月17日にbpftrace版、runqlen(8)は2016年12月12日にBCC版・2018年10月7日にbpftrace版を作成した。両ツールはCPUスケジューラレイテンシ([[スケジューラレイテンシ]])を定量化する代表的なツールである。(Source: [[@2023__OReillyJapan__詳解 システム・パフォーマンス 第2版 - Chapter 6 CPU]] §6.6.16, §6.6.17) - **cpudist(8)の作者**: 2005年にSolaris用にcpudistsヒストグラムツールを作成し、2016年6月29日にサッシャ・ゴールドシュタインがBCC版cpudist(8)を作成した(各スレッドのon-CPU時間分布を示す)。(Source: [[@2023__OReillyJapan__詳解 システム・パフォーマンス 第2版 - Chapter 6 CPU]] §6.6.15) - **softirqs(8)/hardirqs(8)の作者**: softirqs(8)のBCC版を2015年10月20日に、hardirqs(8)のBCC版を2015年10月19日(自作のinttimes.d/intr.dツールがもとになる)に作成した。イベント回数ではなく処理時間そのものを示す点が既存の`/proc/softirqs`・`/proc/interrupts`と異なり、一般的なCPUプロファイラでは見えない割り込み処理のCPU消費を可視化する。(Source: [[@2023__OReillyJapan__詳解 システム・パフォーマンス 第2版 - Chapter 6 CPU]] §6.6.18, §6.6.19) - **ファイルシステム可観測性ツール群の作者**: opensnoop(8)(2004年に最初のバージョンを作成、2015年9月にBCC版、2018年9月にbpftrace版)、filetop(8)(2016年2月6日、ウィリアム・ルフェーブルのtop(1)にヒントを得て作成)、cachestat(8)(2014年12月28日に実験的ftraceツールとして作成、アラン・マカリーヴィが2015年11月にBCCへ移植)、ext4dist(8)/ext4slower(8)(2016年2月にBCC版を作成、2012年に自作したZFSツールが基礎)など、ファイルシステムのオープン・読み書きレイテンシを可視化するBPFツール群の作者である。『詳解 システム・パフォーマンス 第2版』8章では、これらのツールがLinuxにファイルシステムオペレーションの統計量がほぼ存在しない状況(NFS以外)を補う手段として位置づけられている。(Source: [[@2023__OReillyJapan__詳解 システム・パフォーマンス 第2版 - Chapter 8 ファイルシステム]] §8.5.4, §8.6.10〜§8.6.14) - **ネットワーク可観測性ツール群の作者**: tcplife(8)(ジュリア・エヴァンスのアイデアに基づき2016年10月18日に作成、BCC・bpftrace両版あり。TCPセッションの状態変化イベントをトレースするためパケット単位のスニッフィングよりオーバーヘッドが低く本番環境で継続実行できる)、tcptop(8)(ウィリアム・ルフェーブルのtop(1)にヒントを得て2005年に作成、2016年9月2日にBCC版)、tcpretrans(8)(2011年に類似ツールを作成、2014年にFtrace版、2016年2月14日にBCC版)、Solaris版nicstat(1)(Linux版はTim Cookが開発)、tcpsynbl.bt(SYNバックログの飽和をヒストグラムで可視化、2019年4月19日作成)、socketio.bt(プロセス・向き・プロトコル・ポート別のソケットI/Oを集計)の作者である。『詳解 システム・パフォーマンス 第2版』10章では、これらのステート単位トレーシングツールが、CPU・ストレージへのオーバーヘッドが高いパケットキャプチャ(tcpdump)の代替として位置づけられている。(Source: [[@2023__OReillyJapan__詳解 システム・パフォーマンス 第2版 - Chapter 10 ネットワーク]] §10.6.7, §10.6.9〜§10.6.12) - **Netflix本番クラウドインスタンスのネットワークsysctlチューニング例**: 10章では、net.core.default_qdisc=fq・net.ipv4.tcp_congestion_control=bbr・net.ipv4.tcp_slow_start_after_idle=0・net.ipv4.tcp_tw_reuse=1など14個のパラメータのみをブート時に変更する実例を「レシピではなく現時点での一例」として提示した。輻輳制御アルゴリズムBBRへの切り替えにより、パケット消失の激しい環境でスループットを3倍に向上させたことにも言及している。(Source: [[@2023__OReillyJapan__詳解 システム・パフォーマンス 第2版 - Chapter 10 ネットワーク]] §10.4.1.2.5, §10.8.1.1) - **ハイパーバイザー構成のA/B分類とNitroの位置づけ**: 11章では、タイプ1/タイプ2という従来のハイパーバイザー分類が技術進歩で厳密には適用できなくなったとして、構成A(ネーティブハイパーバイザー、例: Xen)・構成B(ホストOSカーネル内で実行、例: KVM)という独自の分類を提案した[Gregg 19]。AWS Nitroハイパーバイザーについては、QEMUのようなI/Oプロキシを一切使わずハードウェアサポートに全面依拠しベアメタルに近い性能を提供すると2017年のブログ記事[Gregg 17e]をもとに解説している。(Source: [[@2023__OReillyJapan__詳解 システム・パフォーマンス 第2版 - Chapter 11 クラウドコンピューティング]] §11.2, §11.2.2.4) - **コンテナCPU抑制診断フローチャートとkvmexits.btの作者**: throttled_time・非自発的コンテキストスイッチ・ホストのアイドルCPU・cpusetの使用率・他テナントのアイドル状態の5指標からコンテナのCPU抑制原因(帯域幅/cpuset/シェア)を切り分けるフローチャートを2017年のDockerCon講演で発表した[Gregg 17g]。また、KVMのゲスト終了理由を終了時間のヒストグラムで表示するbpftraceツールkvmexits(8)を『BPF Performance Tools』(2019)で発表している。(Source: [[@2023__OReillyJapan__詳解 システム・パフォーマンス 第2版 - Chapter 11 クラウドコンピューティング]] §11.3.4.2.5, §11.2.4.1.2) - **ディスクI/O可観測性ツール群(biolatency・biosnoop・biostacks)の作者**: 自作していたiolatencyツールをもとに、biolatency(8)(ディスクI/Oレイテンシのヒストグラム)を2015年9月20日にBCC版・2018年9月13日にbpftrace版で作成した(ツール名の"b"はブロックI/O対象を明示するために追加)。個々のディスクI/Oを1行で表示するbiosnoop(8)は2003年に開発したツールをもとに2015年9月16日にBCC版・2017年11月15日にbpftrace版を作成、ブロックI/O要求時間とI/O初期化スタックトレースを表示するbiostacks(8)は2019年3月19日に『BPF Performance Tools』のために作成した。(Source: [[@2023__OReillyJapan__詳解 システム・パフォーマンス 第2版 - Chapter 9 ディスク]] §9.6.6, §9.6.7, §9.6.9) - **レイテンシヒートマップとオフセットヒートマップの考案・普及**: 2008年、Sun MicrosystemsのZFSストレージアプライアンス(Analytics機能)の分析のためにレイテンシヒートマップ(x軸時間・y軸レイテンシ・z軸イベント数を色で表現)を考案し、数百万イベント規模までスケールする可視化として広めた(Grafana等に普及)。1995年にRichard McDougallが始めたオフセットヒートマップ(taztool)の系譜を引き、著者自身が2006年に作成したDTraceTazToolでもディスクオフセットの可視化を実演している。ディスクごとの使用率を可視化する使用率ヒートマップも考案した。([[レイテンシヒートマップ]]、Source: [[@2023__OReillyJapan__詳解 システム・パフォーマンス 第2版 - Chapter 9 ディスク]] §9.7.3〜§9.7.5) - **アクティブベンチマーキングとベンチマーキングチェックリストの提唱**: 『詳解 システム・パフォーマンス 第2版』12章では、ベンチマーク実行中に可観測性ツールで分析するアクティブベンチマーキング[Gregg 14d]と、ベンチマーキングのミス・不正のパターンを16種類に整理した分類、「なぜ倍ではないのか」等6項目のベンチマーキングチェックリスト[Gregg 18d]、ベンダー結果を評価する「ベンチマークについて問うべきこと」の詳細な問いのリストを提示した。bonnie++の「文字単位のシーケンシャル出力」テストがiostat(1)・bpftrace・cachestat(8)・strace(1)の組み合わせで実はファイルシステムキャッシュへの1バイト書き込みだったと判明する分析ケーススタディや、Sun ZFS Storage Applianceの限界をランプ負荷とPerl製ロードジェネレータで発見し世界記録として扱われた事例、「製品がベンチマークで勝てる確率が五分五分なら、普通は負ける」という『ベンチマークの逆説』[Gregg 14c]を通じて、体系的なベンチマーク分析メソドロジを解説している。([[ベンチマーキング]]、Source: [[@2023__OReillyJapan__詳解 システム・パフォーマンス 第2版 - Chapter 12 ベンチマーキング]] §12.1.3, §12.3.2, §12.3.7, §12.3.10, §12.4) - **perf(1)イベントモデルとプローブイベントの体系化**: 『詳解 システム・パフォーマンス 第2版』13章では、[[perf]](1) が扱うイベントを Hardware event・Software event・Tracepoint event・SDT event 等に分類し、[[kprobe]]・[[uprobe]]・USDT を「プローブイベント」として統一的に扱う perf(1) の設計を解説した。カーネル関数の引数取得には debuginfo の `--vars`、参照システムでのレジスタ調査、ABI 知識、BTF という4通りの方法があることを示し、本番環境で debuginfo がない場合の実務的な対処手順を提示している。オンラインで発表した1行プログラム集[Gregg 20h]の抜粋も本章に収録した。(Source: [[@2023__OReillyJapan__詳解 システム・パフォーマンス 第2版 - Chapter 13 perf]] §13.3, §13.7, §13.2) - **perf-toolsの作者**: [[Ftrace]] と perf(1) に基づく高度なパフォーマンス分析シェルスクリプト群「[[perf-tools]]」を、拡張BPFのないLinux 3.2を使っていた当時のNetflixクラウド向けに開発し、Netflixのサーバーにデフォルトインストールした。execsnoop(8)・iolatency(8)・cachestat(8)などの単一目的ツールと、funccount(8)・funcgraph(8)・kprobe(8)などの多目的ツールに分類される。その後多くのツールをBPF版(BCC)に書き換えたが、funccount(8)はFtrace関数プロファイラを使うためBCCのkprobeベースBPF版より効率的で制約が少なく、funcgraph(8)はFtrace関数グラフトレーサーを使うためBCCに対応版がないなど、perf-toolsが今も持つ利点を『詳解 システム・パフォーマンス 第2版』14章で説明した。著者はBPFツールのクロスチェック・デバッグのためにperf-toolsを使うこともあるとしている。([[perf-tools]]、Source: [[@2023__OReillyJapan__詳解 システム・パフォーマンス 第2版 - Chapter 14 Ftrace]] §14.13, §14.13.6) - **Ftrace hist トリガーへの機能提案者**: [[kprobe]]/[[uprobe]] イベントトレーシングの利用に加え、著者はカーネルスタックトレース全体をヒストグラムのキーとして使える機能を Ftrace メンテナのトム・ザヌッシに提案し、実装された(`hist:key=stacktrace`)。Ftrace の発展を、PID/スタックトレース別集計や合成イベントによるカスタムレイテンシ計算など、段階的に BPF が必要とされていた機能を Ftrace 単体で追いついてきた歴史として描写している。(Source: [[@2023__OReillyJapan__詳解 システム・パフォーマンス 第2版 - Chapter 14 Ftrace]] §14.10.6〜§14.10.7) - **BCC の共同開発者、bpftrace の主要コントリビュータ**: [[BCC]](BPF Compiler Collection)を作り、多くのトレーシングツールを開発した。[[bpftrace]] は [[Alastair Robertson]] が開発し、著者も主要なコントリビュータとして関与している。『詳解 システム・パフォーマンス 第2版』15章では、BCC(複雑なカスタムツール向け、開発に bpftrace の10倍の時間・行数を要する)と bpftrace(引数0〜1個のワンライナー向け)の役割分担を「C プログラムとシェルスクリプトの違い」に例えて説明し、bpftrace で試作してから必要に応じて BCC へ移植する開発フローを自ら実践しているとする。(Source: [[@2023__OReillyJapan__詳解 システム・パフォーマンス 第2版 - Chapter 15 BPF]] §15.1, §15.1.7, §15.2) - **Netflix コンテナ移行のパフォーマンス障害を分析した実務ケーススタディの執筆**: 『詳解 システム・パフォーマンス 第2版』16章では、Netflix のマイクロサービスを VM からコンテナプラットフォーム Titus へ移行した際に要求レイテンシが3、4倍改善するという「うますぎる」報告を調査した実際の障害調査を、60秒チェックリスト→[[USE メソッド]]→PMC→ソフトウェアイベント→トレーシングという手順で時系列に記録した。`pmcarch(8)` による [[Instructions Per Cycle]] とLLCヒット率の実測(VM 0.57/30%、コンテナ1.52/90%)、`perf stat -e cs` による[[コンテキストスイッチ]]頻度の比較(VM 毎秒約200万回、コンテナ毎秒約1000〜1400回)、`cpudist(8)` によるon-CPU時間分布の比較を組み合わせ、パフォーマンス差を「コンテナに隣人がいなかったこと」「LLCサイズとワークロードの違い」「CPU負荷の違い」という3要因の重なりとして説明した。本 USENIX LISA 2019 発表 [Gregg 19h] を元に書籍化したこの章は、本書のメソドロジが実際の障害調査でどう連鎖するかを示す唯一のケーススタディである。(Source: [[@2023__OReillyJapan__詳解 システム・パフォーマンス 第2版 - Chapter 16 ケーススタディ]] §16.1) - **`Observability Engineering`(2nd Edition)による横断的な引用**: Honeycombの著者陣は第20章冒頭の注釈で、分散システムオブザーバビリティとの重なりに絞って扱うと断ったうえで、著者の *BPF Performance Tools*(2019)と *Systems Performance*(2nd ed. 2020、邦訳『詳解 システム・パフォーマンス 第2版』)をパフォーマンスエンジニアリング分野を深掘りするための代表的な参考文献として挙げる。本 wiki が両書籍(著者の原著と、本エンティティが集約する『詳解 システム・パフォーマンス 第2版』全16章)を独立に ingest していることは、オブザーバビリティ実務書とシステムパフォーマンス専門書という異なる系譜の著者たちが、著者の体系(USEメソッド・フレームグラフ・レイテンシ分析等)を共通言語として参照していることを裏づける。(Source: [[@2026__OReilly__Observability Engineering 2E - Chapter 20 Performance Engineering with Observability]] "The Case for Performance Engineering") ## 著書 - *Systems Performance: Enterprise and the Cloud*(1st ed. 2013, 2nd ed. 2020) - *BPF Performance Tools*(2019) ## 関連 - 出典: [[@2017__brendangregg.com__CPU Utilization is Wrong]] / [[@2026__技術評論社__実践的パフォーマンスエンジニアリングによるAI高速化 - Chapter 1 パフォーマンスエンジニアリング概論]] / [[@2023__OReillyJapan__詳解 システム・パフォーマンス 第2版 - Chapter 4 可観測性ツール]] / [[@2023__OReillyJapan__詳解 システム・パフォーマンス 第2版 - Chapter 3 オペレーティングシステム]] / [[@2023__OReillyJapan__詳解 システム・パフォーマンス 第2版 - Chapter 2 メソドロジ]] / [[@2023__OReillyJapan__詳解 システム・パフォーマンス 第2版 - Chapter 1 イントロダクション]] / [[@2023__OReillyJapan__詳解 システム・パフォーマンス 第2版 - Chapter 7 メモリ]] / [[@2023__OReillyJapan__詳解 システム・パフォーマンス 第2版 - Chapter 5 アプリケーション]] / [[@2023__OReillyJapan__詳解 システム・パフォーマンス 第2版 - Chapter 8 ファイルシステム]] / [[@2023__OReillyJapan__詳解 システム・パフォーマンス 第2版 - Chapter 6 CPU]] / [[@2023__OReillyJapan__詳解 システム・パフォーマンス 第2版 - Chapter 9 ディスク]] / [[@2023__OReillyJapan__詳解 システム・パフォーマンス 第2版 - Chapter 10 ネットワーク]] / [[@2023__OReillyJapan__詳解 システム・パフォーマンス 第2版 - Chapter 11 クラウドコンピューティング]] / [[@2023__OReillyJapan__詳解 システム・パフォーマンス 第2版 - Chapter 12 ベンチマーキング]] / [[@2023__OReillyJapan__詳解 システム・パフォーマンス 第2版 - Chapter 13 perf]] / [[@2023__OReillyJapan__詳解 システム・パフォーマンス 第2版 - Chapter 14 Ftrace]] / [[@2023__OReillyJapan__詳解 システム・パフォーマンス 第2版 - Chapter 15 BPF]] / [[@2023__OReillyJapan__詳解 システム・パフォーマンス 第2版 - Chapter 16 ケーススタディ]] / [[@2026__OReilly__Observability Engineering 2E - Chapter 20 Performance Engineering with Observability]] - 概念: [[CPU利用率]] / [[Instructions Per Cycle]] / [[ハードウェアカウンタ]] / [[BPF]] / [[DTrace]] / [[継続的プロファイリング]] / [[パフォーマンスエンジニアリング]] / [[uprobe]] / [[kprobe]] / [[動的計装]] / [[USE メソッド]] / [[ドリルダウン分析]] / [[コンテキストスイッチ]] / [[待ち行列理論]] / [[アムダールの法則]] / [[ユニバーサルスケーラビリティ法則]] / [[フレームグラフ]] / [[オブザーバビリティ]] / [[カナリアテスト]] / [[アプリケーション並行実行モデル]] / [[同期プリミティブ]] / [[スレッド状態分析]] / [[スケジューラレイテンシ]] / [[RAID]] / [[IOスケジューラ]] / [[レイテンシヒートマップ]] / [[ハードディスク信頼性]] / [[TCP輻輳制御アルゴリズム]] / [[TCPバックログキューとSYNクッキー]] / [[クラウドコンピューティング]] / [[コンテナ仮想化]] / [[ベンチマーキング]] - エンティティ: [[Netflix]] / [[bpftrace]] / [[BCC]] / [[perf]] / [[Ftrace]] / [[trace-cmd]] / [[perf-tools]] / [[KernelShark]] / [[Steven Rostedt]] / [[Alastair Robertson]]