從火焰圖（Flame Graph）讀懂你的 .NET 應用程式效能瓶頸

當 APM 指標告訴你「慢」，但你不知道「為什麼」

你的監控儀表板亮起了紅燈——P99 延遲突破 2 秒，GC 暫停時間激增，CPU 使用率在 80% 附近徘徊。你翻遍了 Application Insights 的 Trace，看到的是一串串 HttpClient 呼叫和 SQL 查詢，卻找不到真正的根因。

這正是火焰圖（Flame Graph）派上用場的時刻。

火焰圖不是新技術——Brendan Gregg 在 Netflix 工作期間將其推廣，最初用於 Linux CPU profiling。但在 .NET 生態系中，隨著 dotnet-trace、PerfView、以及 Visual Studio Profiler 的成熟，它已成為定位效能瓶頸最直接的工具。本文將帶你從工具鏈建立到實戰解讀，完整走一遍 .NET 火焰圖分析流程。

先決條件與背景知識

環境需求

.NET 8 SDK（dotnet --version 應顯示 8.x.x 以上）

dotnet-trace 全域工具：dotnet tool install --global dotnet-trace

dotnet-counters：dotnet tool install --global dotnet-counters

dotnet-gcdump：dotnet tool install --global dotnet-gcdump

SpeedScope（瀏覽器版）：speedscope.app

或 PerfView 2.0.x（Windows 限定，功能最完整）

你需要理解的核心概念

Sampling vs Instrumentation Profiling

火焰圖通常基於 sampling profiler：每隔固定時間間隔（例如 1ms）對所有執行緒抓一次 call stack snapshot。這個方式開銷極低（通常 < 5% CPU overhead），適合在 staging 甚至 production 環境使用。

相較之下，instrumentation profiler 在每個函式進出點插樁，精確度高但開銷大——不適合線上使用。

CLR 的 EventPipe 機制

自 .NET Core 2.1 起，CLR 內建 EventPipe，讓 dotnet-trace 能透過跨平台的 IPC socket 即時收集 runtime events，包含 GC、JIT、thread pool 狀態，以及最關鍵的 CPU sample stacks。這是不需要 root 權限、不依賴 perf/ETW 的重要優勢。

Step 1：建立可重現的效能問題情境

在分析之前，先有一個可重現的慢速場景。以下是一個刻意設計的 ASP.NET Core 8 Web API：

csharp

// Controllers/OrderController.cs

[ApiController]

[Route("api/[controller]")]

public class OrderController : ControllerBase

{

private readonly IOrderService _orderService;

public OrderController(IOrderService orderService)

=> _orderService = orderService;

[HttpGet("{id}")]

public async Task GetOrder(int id)

{

var order = await _orderService.GetOrderWithDetailsAsync(id);

return Ok(order);

}

}

csharp

// Services/OrderService.cs

public class OrderService : IOrderService

{

private readonly AppDbContext _db;

public OrderService(AppDbContext db) => _db = db;

public async Task GetOrderWithDetailsAsync(int orderId)

{

// 問題 1：N+1 Query 隱藏在同步迴圈中

var order = await _db.Orders

.AsNoTracking()

.FirstOrDefaultAsync(o => o.Id == orderId);

var items = new List();

foreach (var itemId in order.ItemIds) // ItemIds 是個 int[]

{

// 每次迴圈都發一次 DB 查詢

var item = await _db.Items.FindAsync(itemId);

items.Add(MapToDto(item));

}

// 問題 2：不必要的 CPU 密集序列化

var json = System.Text.Json.JsonSerializer.Serialize(items);

var reparsed = System.Text.Json.JsonSerializer.Deserialize>(json);

return new OrderDto { Order = order, Items = reparsed };

}

private OrderItemDto MapToDto(Item item)

{

// 問題 3：正規表示式未快取

var cleaned = Regex.Replace(item.Description, @"\s+", " ");

return new OrderItemDto { Id = item.Id, Description = cleaned };

}

}

這段程式碼包含三個典型的效能陷阱，讓我們用火焰圖把它們找出來。

Step 2：收集 CPU Profile

啟動應用程式並找出 PID

bash

dotnet run --configuration Release --project ./OrderApi

另一個 terminal

dotnet-counters ps

輸出：

12345 OrderApi /path/to/OrderApi

使用 dotnet-trace 收集 30 秒的 CPU sample

bash

dotnet trace collect \

--process-id 12345 \

--providers Microsoft-DotNETCore-SampleProfiler:0x0F:5 \

--format speedscope \

--output ./profiles/order-api-$(date +%Y%m%d-%H%M%S).speedscope.json \

-- sleep 30

關鍵參數說明：

Microsoft-DotNETCore-SampleProfiler:0x0F:5：啟用 CPU sampling，關鍵字 0x0F 涵蓋 thread/GC/JIT，verbosity 5 = Verbose

--format speedscope：輸出 SpeedScope 格式，可直接在瀏覽器開啟

同時施加負載

bash

使用 bombardier 或 hey 工具

hey -n 1000 -c 20 http://localhost:5000/api/order/1

---

## Step 3：解讀火焰圖

將 `.speedscope.json` 拖入 [speedscope.app](https://www.speedscope.app)，你會看到類似下圖的結構：

[Thread 1 - ASP.NET Request Handler]

└─ Microsoft.AspNetCore.Hosting.HostingApplication.ProcessRequestAsync

└─ OrderController.GetOrder

└─ OrderService.GetOrderWithDetailsAsync

├─ [38%] Microsoft.EntityFrameworkCore.Query.Internal.QueryingEnumerable.AsyncEnumerator.MoveNextAsync

│ └─ Npgsql.NpgsqlCommand.ExecuteReaderAsync ← N+1 在這裡爆發

├─ [22%] System.Text.Json.JsonSerializer.Serialize

│ └─ System.Text.Json.Utf8JsonWriter.WriteStartObject ← 多餘序列化

└─ [15%] System.Text.RegularExpressions.Regex.Replace ← 未快取 Regex

火焰圖閱讀法則

看寬度，不看高度：x 軸代表時間（或 sample 數），y 軸代表 call stack 深度。一個函式的「寬度」越寬，代表它佔用的 CPU 時間越多。

找「平頂」（plateau）：如果某個 frame 的頂部是平的（沒有子 frame 或子 frame很窄），代表這裡是 CPU 熱點（hot spot）——CPU 時間實際消耗在這個函式內部。

區分 on-CPU vs off-CPU：SpeedScope 的 "Time Order" 模式顯示時間序列，可以看到執行緒在何時進入等待（off-CPU）。如果你的 API 慢但 CPU 使用率不高，問題通常在 I/O 等待，而非計算。

Step 4：從火焰圖定位到程式碼，逐一修復

問題 1：N+1 Query（38% CPU 在 DB 驅動層）

火焰圖顯示 Npgsql.NpgsqlCommand.ExecuteReaderAsync 被呼叫了 N 次（每個 item 一次）。修復方式是批次查詢：

csharp

// 修復後：一次查詢取回所有 items

public async Task GetOrderWithDetailsAsync(int orderId)

{

var order = await _db.Orders

.AsNoTracking()

.Include(o => o.Items) // EF Core 的 eager loading

.FirstOrDefaultAsync(o => o.Id == orderId);

// 或者用 IN 查詢（適合非 navigation property 場景）

var itemIds = order.ItemIds;

var items = await _db.Items

.Where(i => itemIds.Contains(i.Id))

.AsNoTracking()

.ToListAsync();

return new OrderDto

{

Order = order,

Items = items.Select(MapToDto).ToList()

};

}

問題 2：多餘的 Serialize/Deserialize（22% CPU）

在火焰圖中，System.Text.Json.JsonSerializer.Serialize 緊接著 Deserialize，這是典型的「深複製替代方案」反模式。直接用 LINQ Select 投影：

csharp

// 移除多餘的 JSON round-trip，直接映射

return new OrderDto

{

Order = MapOrderToDto(order),

Items = items.Select(MapToDto).ToList() // 直接投影，零序列化開銷

};

問題 3：未快取的 Regex（15% CPU）

Regex.Replace 每次呼叫都會重新編譯正規表示式。.NET 6 之後有更優雅的解法：

csharp

// 舊方式（每次都編譯）

var cleaned = Regex.Replace(item.Description, @"\s+", " ");

// 推薦方式 1：靜態編譯 Regex（.NET 7+ Source Generator）

public partial class OrderService

{

[GeneratedRegex(@"\s+", RegexOptions.Compiled)]

private static partial Regex WhitespaceRegex();

private OrderItemDto MapToDto(Item item)

{

var cleaned = WhitespaceRegex().Replace(item.Description, " ");

return new OrderItemDto { Id = item.Id, Description = cleaned };

}

}

// 推薦方式 2：靜態欄位（.NET 6 以下相容）

private static readonly Regex _whitespaceRegex =

new Regex(@"\s+", RegexOptions.Compiled | RegexOptions.CultureInvariant);

[GeneratedRegex] Source Generator 在編譯期產生狀態機程式碼，執行時無需動態編譯，效能是 Regex.Compiled 的 2–4 倍。

Step 5：GC 壓力的火焰圖分析

CPU sampling 火焰圖只能看到 on-CPU 的活動。若你懷疑是 GC 壓力導致延遲（常見於大量小物件配置場景），需要結合 dotnet-counters 監控：

bash

dotnet-counters monitor \

--process-id 12345 \

--counters System.Runtime[gc-heap-size,gen-0-gc-count,gen-1-gc-count,gen-2-gc-count,alloc-rate]

[System.Runtime]

Allocation Rate (B / 1 sec) 245,678,912

GC Heap Size (MB) 412

Gen 0 GC Count (Count / 1 sec) 48

Gen 1 GC Count (Count / 1 sec) 12

Gen 2 GC Count (Count / 1 sec) 2

每秒 245MB 的配置速率、每秒 48 次 Gen 0 GC——這是嚴重的 GC 壓力。搭配 dotnet-gcdump 取得 heap snapshot：

bash

dotnet-gcdump collect --process-id 12345 --output ./profiles/heap.gcdump

用 PerfView 開啟 .gcdump，在 "GC Heap Alloc Ignore Free (Coarse Sampling)" 視圖可以看到哪些類型佔用了最多配置。

常見的 GC 壓力修復模式：

csharp

// 問題：在熱路徑上大量建立 string

public string BuildCacheKey(int orderId, string region, DateTime date)

=> $"order:{orderId}:{region}:{date:yyyyMMdd}"; // 每次都配置新 string

// 修復：使用 ArrayPool + Span 或 MemoryCache key struct

// 對於簡單場景，string interning 或 static dictionary 即可

private static readonly ConcurrentDictionary<(int, string, DateTime), string> _keyCache = new();

public string BuildCacheKey(int orderId, string region, DateTime date)

=> _keyCache.GetOrAdd((orderId, region, date.Date),

static k => $"order:{k.Item1}:{k.Item2}:{k.Item3:yyyyMMdd}");

常見陷阱與如何避免

陷阱 1：在 Debug 模式下分析

Debug build 關閉了 JIT 最佳化，火焰圖會顯示大量根本不存在於 Release 的 overhead。永遠在 --configuration Release 下收集 profile，並確認 true 沒有被覆蓋。

陷阱 2：忽略 Inlining 造成的 stack 扁平化

JIT 會積極 inline 小函式，導致它們在火焰圖中「消失」。如果你懷疑某個函式有問題但在圖中看不到，可以暫時加上 [MethodImpl(MethodImplOptions.NoInlining)] attribute 強制保留 stack frame，分析後再移除。

陷阱 3：只看 CPU 火焰圖，錯過 I/O 瓶頸

若 API 慢但火焰圖的 CPU 佔用很低，問題可能在：

同步等待 async 操作（.Result 或 .Wait()）造成執行緒飢餓

Thread Pool 耗盡（用 dotnet-counters 看 threadpool-queue-length）

外部服務延遲（需要 distributed tracing，而非 profiling）

陷阱 4：在單一 request 下分析

單次 request 的噪訊太高。務必在持續負載下收集至少 15–30 秒，讓 sampling 數量足以統計顯著。

陷阱 5：混淆 Wall-clock time 與 CPU time

SpeedScope 的 "Left Heavy" 模式聚合所有 samples，顯示的是 CPU time。如果一個函式花了 500ms 但都在等 lock（Monitor.Enter），它的 CPU time 會很低，但 wall-clock time 很長。這種場景需要用 dotnet-trace 收集 Microsoft-Windows-DotNETRuntime:ContentionStart 事件來分析 lock contention。

最佳實踐

1. 建立效能基準線（Baseline）

在每次部署前後各跑一次 profile，用 diff 方式比較，而非靠主觀感受判斷是否變慢。可以將 dotnet-trace 整合進 CI/CD pipeline，搭配 BenchmarkDotNet 做回歸測試。

1. 使用 Custom EventSource 標記業務邏輯邊界

csharp

// 讓火焰圖能清楚區分業務層邊界

[EventSource(Name = "OrderApi-OrderService")]

public sealed class OrderServiceEventSource : EventSource

{

public static readonly OrderServiceEventSource Log = new();

[Event(1, Level = EventLevel.Informational)]

public void GetOrderStart(int orderId) => WriteEvent(1, orderId);

[Event(2, Level = EventLevel.Informational)]

public void GetOrderStop(int orderId, int itemCount) => WriteEvent(2, orderId, itemCount);

}

// 在服務中使用

OrderServiceEventSource.Log.GetOrderStart(orderId);

// ... 業務邏輯 ...

OrderServiceEventSource.Log.GetOrderStop(orderId, items.Count);

加入 EventSource 後，dotnet-trace 收集時加上 OrderApi-OrderService provider，火焰圖中業務邏輯的時間範圍就會清晰標記出來。

1. 善用 Activity 和 OpenTelemetry 搭配 Profiling

csharp

// 用 ActivitySource 標記，可以同時在 Jaeger/Zipkin 和火焰圖中看到相同的操作

private static readonly ActivitySource _activitySource =

new("OrderApi.OrderService", "1.0.0");

public async Task GetOrderWithDetailsAsync(int orderId)

{

using var activity = _activitySource.StartActivity("GetOrderWithDetails");

activity?.SetTag("order.id", orderId);

// ... 業務邏輯 ...

}

1. Production Profiling 的安全守則

永遠設定收集時限（-- sleep 30 或程式碼中的 timeout）

使用 --buffersize 限制記憶體用量（預設 256MB）

優先在 Pod 的副本上收集，避免影響主要流量

Kubernetes 環境可用 kubectl exec 進入 pod 後執行 dotnet-trace

總結與下一步

火焰圖的價值在於它讓「直覺」變得可驗證。在引入優化之前，你必須能指著圖說「這 38% 的寬度就是問題所在」；在優化之後，你必須能展示寬度縮小了。這才是有紀律的效能工程，而非猜測驅動的調教。

本文示範的三個核心問題——N+1 Query、多餘序列化、未快取 Regex——在真實專案中出現頻率極高，而且往往不會觸發明顯的 exception，只是默默地讓 P99 往上爬。

下一步建議：

深入 GC 分析：學習使用 dotnet-gcdump 搭配 PerfView 的 "GC Heap Alloc" 視圖，定位 LOH（Large Object Heap）碎片化問題。

Lock Contention 分析：在 dotnet-trace 中加入 Microsoft-Windows-DotNETRuntime:ContentionKeyword 收集爭鎖事件，找出 ConcurrentDictionary 或 lock 的熱點。

Async/Await 狀態機分析：閱讀 Kathleen Dollard 的 "Diagnosing Thread Pool Starvation" 系列，理解為何有時 async 程式碼的火焰圖看起來「空空的」。

持續效能監控：將 dotnet-counters 的關鍵指標（alloc-rate、gen-2-gc-count、threadpool-queue-length）接入 Prometheus + Grafana，在問題爆發前就建立預警。

效能調教從來不是一次性工作，而是隨著業務成長持續進行的工程紀律。火焰圖只是你武器庫中最鋒利的那把刀——知道何時拔出它，才是真正的本事。