今日から始める pprof
ワークショップに外れてしまったので、一人で資料を見ながらやってみる radish-miyazaki.icon
Go におけるパフォーマンスプロファイルとは
プログラムの実行速度の律速
統計的に特定の数値(CPU 使用率、メモリ使用率、スレッド数)などのコールスタック(関数)レベルで取得
関連する標準パッケージ(サンプリングツール)
この場合、設定されたエンドポイントに HTTP GET アクセスが走る
/debug/pprof/profile: CPU 使用量
/debug/pprof/heap: ヒープサイズ
/debug/pprof/block: ゴルーチン ブロック /debug/pprof/mutex: mutex ロックの保持 /debug/pprof/trace: トレース
ビジュアライザー(Web UI)もある: go tool pprof -http :<ポート番号>
-http を付けないと、インタラクティブモードで立ち上がる
https://gyazo.com/f8632fa7ec5e974de26925ab8b848911
Flame Graph
長い = リソースを使っている = 悪い
https://gyazo.com/df12e3e5ff7118433d66d47b3582d38b
Top
Linux の top と同じで、スタックをリソース消費順に表形式で表示 https://gyazo.com/01ff40ba8316e1f0c650437389f8a84c
Graph
箱が大きい方がリソース消費が多い
比較の場合、緑(マイナス = 改善)〜灰色〜赤(プラス = 赤)でグラデーション
https://gyazo.com/515682449884b1c593d01acd1ebed780
Source: 行レベル(!?)でのリソース消費を表示
https://gyazo.com/778944d86da4dd93541a646c78a6bad7
他にも Peek、Diassemble などがある
ワークショップでは CLI アプリケーションの改善を行うので、runtime/pprof を用いる
改善するにあたっての結果の見方
基本的には自分が書いたものに原因があると思え
標準パッケージや著名なパッケージはベンチマークテストを実行している
Flat が遅い場合 → アルゴリズムに問題がある Flat: その関数自体で直接使われた時間やメモリを表す
Cum が遅い場合 → 外部関数の呼び出し方に問題がある Cum: 累計時間を表し、その関数とその呼び出すすべての子関数で使われた時間やメモリの合計
プロファイルは常に計測すべき
改善結果は計測によってのみ判断される
客観的には共有するには図表が効率的
差分を確認する
$ go tool pprof -http :9999 -base cpu.prof cpu.prof.2
https://gyazo.com/2f06420b968e28e9f38ccb731ec7dbf4
https://gyazo.com/70c0588e15ec40fcb6157c200668ca65
とはいえ、上記のようにプロファイルを取ることはあまりない
ベンチマークテスト時にプロファイルも出すので、実際にはこれを用いることが多い
$ go test -bench=. -cpuprofile=cpu.prof
ヒープ取得時には -memprofile を付ける
$ go test -bench=. -memprofile=mem.prof
継続的に動かしたい
CI だとテスト環境
本当だったら、本番環境で継続的に取得したい
∵ 常時稼働のサービスの場合、パフォーマンスの問題は急にやってくるため
https://gyazo.com/82bb1cd25ba4adc093e776d0688c329b
CNCF のオブザーバビリティ白書の重要な テレメトリ として挙げている「プロファイル」も継続的なプロファイル ログ、メトリクス、トレース、プロファイル、ダンプ ...
自作することもできるが、あまり現実的ではない
専用のサービスを使う
https://gyazo.com/aef7790abc90630960cb935e2404ca24