Day 041 — pprofによるプロファイリング②（メモリ）（概念編: サンプリングと4つの計測軸）

📚 背景知識（読んでから問題へ）

Day 038〜040では、実際にメモリの問題（アロケーション過多・スライス共有リーク）を含むコードを題材に、ヒーププロファイルを「読む」実践をしてきました。今回はその土台となる、Goのメモリプロファイラがそもそも何を・どうやって計測しているかという仕組みそのものを扱います。ここを正確に理解していないと、「プロファイルに出てこないから問題ない」という誤った結論を出しかねません。

Goのヒーププロファイルは、CPUプロファイルと同様にサンプリングベースです。すべてのアロケーションを記録すると実行速度が大きく落ちるため、ランタイムはruntime.MemProfileRate（デフォルト 512 * 1024 = 512KB）というバイト数のしきい値を使い、確保したバイト数の累計がこのしきい値を超えるたびに1回、その時点のアロケーションを記録します。つまり、1回あたりのアロケーションサイズが小さいほど「記録される確率」は下がり、代わりに統計的な重み（ウェイト）を掛けて全体量を推定します。

📝 問題

以下の5つの問いに、実行可能なコードを交えて答えてください。

1. runtime.MemProfileRate のデフォルト値（512KB）のまま、1回あたり数十バイトの小さいオブジェクトを大量に確保し続けるコードをプロファイリングした場合、pprof.WriteHeapProfile が出力する結果は「実際に確保されたバイト数」と完全に一致するか、それとも統計的な推定値になるか。サンプリングの仕組みに基づいて説明する
2. alloc_spaceは大きいのにinuse_spaceはほぼゼロ、という結果が出るプログラムを実際に作成し（go run main.goでそのまま動くこと）、これが「リークではなく、単にアロケーションが多いだけ」を意味することを、コード上のロジックとともに説明する
3. 逆に、inuse_spaceが時間とともに増え続けるプログラムの特徴を、問2のコードを流用・改造する形で示す
4. runtime.MemProfileRate = 1 に設定するとどうなるか。得られる情報の精度と、実行時のオーバーヘッドの観点からトレードオフを説明する
5. inuse_spaceのスナップショットは「呼び出した瞬間の正確な使用量」を表すか、それとも「直近の完了済みGCサイクル時点の生存量」を表すか。runtime.GC()を明示的に呼んでからプロファイルを取ることが推奨される理由と合わせて説明する

🔍 ヒント（段階的開示）

📋 コピーpackage main

import (
	"os"
	"runtime"
	"runtime/pprof"
)

var kept [][]byte // inuse_spaceを増やし続けたい場合はここにappendする

func allocateAndMaybeKeep(keep bool) {
	b := make([]byte, 1<<20) // 1MB: スタック割当の上限を超えて確実にヒープ確保させる
	if keep {
		kept = append(kept, b)
	}
	// keep=falseなら b はこの関数を抜けた時点で参照されなくなる
}

func writeHeapProfile(name string) {
	runtime.GC() // 直近のゴミを回収し、inuse_spaceの値を安定させてから記録する
	f, _ := os.Create(name)
	defer f.Close()
	pprof.WriteHeapProfile(f)
}

✅ 模範解答

📋 コピーpackage main

import (
	"fmt"
	"os"
	"runtime"
	"runtime/pprof"
)

// kept はグローバルに保持され続けるバイト列のスライス。
// ここに追加されたものは、プログラム終了までGCの回収対象にならない。
var kept [][]byte

// checksum は allocateChurn の結果を外部から観測可能にするためだけの変数。
// これがないと、bが読み出されないためコンパイラがヒープ確保自体を最適化で消してしまう。
var checksum int

// allocateChurn は「確保してすぐ捨てる」パターンを再現する。
// alloc_space（累計確保量）は大きく積み上がるが、inuse_space（生存量）はほぼ増えない。
func allocateChurn(n int, size int) {
	for i := 0; i < n; i++ {
		b := make([]byte, size)
		b[0] = byte(i)
		checksum += int(b[0]) // bを外部から観測可能な形で使い、確保が最適化で消えないようにする
		// ここでbへの参照はループの次のイテレーションで失われる
	}
}

// allocateLeak は「確保して保持し続ける」パターンを再現する。
// alloc_spaceとinuse_spaceの両方が、呼び出し回数に応じて増え続ける。
func allocateLeak(n int, size int) {
	for i := 0; i < n; i++ {
		b := make([]byte, size)
		b[0] = byte(i)
		kept = append(kept, b) // グローバル変数に保持し続けるため、GC対象にならない
	}
}

func heapStatsMB() (allocMB, inuseMB float64) {
	runtime.GC() // 直近の完了済みGCサイクル時点の値に揃えるため、明示的にGCを実行する
	var m runtime.MemStats
	runtime.ReadMemStats(&m)
	// TotalAlloc: プログラム開始からの累計確保バイト数（alloc_spaceに相当する考え方）
	// HeapAlloc : 現在生きているヒープバイト数（inuse_spaceに相当する考え方）
	return float64(m.TotalAlloc) / 1024 / 1024, float64(m.HeapAlloc) / 1024 / 1024
}

func writeHeapProfile(name string) {
	f, err := os.Create(name)
	if err != nil {
		fmt.Println("プロファイル作成エラー:", err)
		return
	}
	defer f.Close()
	runtime.GC()
	if err := pprof.WriteHeapProfile(f); err != nil {
		fmt.Println("プロファイル書き込みエラー:", err)
	}
}

func main() {
	const n = 5000
	const size = 1 << 20 // 1MB: スタック割当の上限（コンパイラのescape解析でスタックに置ける最大サイズ）を超えて、確実にヒープ確保させる

	fmt.Println("--- サンプリングレート確認 ---")
	fmt.Printf("runtime.MemProfileRate = %d byte\n", runtime.MemProfileRate)
	fmt.Println("(デフォルト512KBごとに1回サンプリングされる。1回1MBの確保なので、ほぼ毎回サンプルとして記録される計算になる)")

	fmt.Println("\n--- パターン1: allocateChurn（確保してすぐ捨てる） ---")
	beforeAlloc, beforeInuse := heapStatsMB()
	allocateChurn(n, size)
	afterAlloc, afterInuse := heapStatsMB()
	fmt.Printf("TotalAlloc差分(alloc_space相当): %.2fMB\n", afterAlloc-beforeAlloc)
	fmt.Printf("HeapAlloc差分(inuse_space相当) : %.2fMB\n", afterInuse-beforeInuse)
	fmt.Printf("checksum(確保が最適化で消えていない確認用): %d\n", checksum)

	fmt.Println("\n--- パターン2: allocateLeak（確保して保持し続ける） ---")
	beforeAlloc, beforeInuse = heapStatsMB()
	allocateLeak(n, size)
	afterAlloc, afterInuse = heapStatsMB()
	fmt.Printf("TotalAlloc差分(alloc_space相当): %.2fMB\n", afterAlloc-beforeAlloc)
	fmt.Printf("HeapAlloc差分(inuse_space相当) : %.2fMB\n", afterInuse-beforeInuse)

	writeHeapProfile("heap.pprof")
	fmt.Println("\nheap.pprof を出力しました。`go tool pprof -top -inuse_space heap.pprof` などで確認できます。")
}

実行結果（実測。数値は環境依存だがパターンの差ははっきり出る）:

📋 コピー--- サンプリングレート確認 ---
runtime.MemProfileRate = 524288 byte
(デフォルト512KBごとに1回サンプリングされる。1回1MBの確保なので、ほぼ毎回サンプルとして記録される計算になる)

--- パターン1: allocateChurn（確保してすぐ捨てる） ---
TotalAlloc差分(alloc_space相当): 5000.02MB
HeapAlloc差分(inuse_space相当) : 0.02MB
checksum(確保が最適化で消えていない確認用): 629340

--- パターン2: allocateLeak（確保して保持し続ける） ---
TotalAlloc差分(alloc_space相当): 5000.49MB
HeapAlloc差分(inuse_space相当) : 5000.15MB

heap.pprof を出力しました。`go tool pprof -top -inuse_space heap.pprof` などで確認できます。

🪜 Step-by-Step 解説

💡 設計思想・なぜこう書くのか

🌐 他言語との比較

🏆 実務での使いどころ

• 本番環境の常時監視への組み込み: net/http/pprofを有効化しておき、定期的（例: 1時間おき）に/debug/pprof/heap?gc=1（gc=1パラメータで取得前に強制GCを実行できる）を取得・保存しておくことで、後から「いつからinuse_spaceが増え始めたか」を時系列で追える
• 問題切り分けの初手: 障害調査でまずalloc_spaceとinuse_spaceの両方を確認し、「GC負荷が高いだけ（パフォーマンス問題）」なのか「生存量が増え続けている（リーク）」なのかを最初に切り分けることで、その後の調査方針（ホットパス最適化 vs 参照関係の追跡）を誤らずに済む
• 精度が必要な場面での一時的なMemProfileRate引き下げ: ステージング環境で再現するリークの発生源を1バイト単位まで絞り込みたい場合に限定してMemProfileRate=1を使い、原因特定後は必ずデフォルトに戻す

⚠️ よくある誤解・ミス

🚀 次のステップ

• 発展: 本問のallocateChurn/allocateLeakをgo tool pprof -http=:8080 heap.pprofで実際に開き、フレームグラフ上でalloc_spaceとinuse_spaceの切り替えがどう見た目を変えるかを目視で確認してみましょう
• 次回予告: ベンチマーク駆動最適化 — Day 038〜041で学んだCPU/メモリプロファイリングの読み方を踏まえ、testing.BによるBefore/Afterの定量比較を通じて最適化のワークフローを一本化します

🎯 自己評価

自分の回答

気づき・メモ