在處理高併發的大規模系統時，最令工程師頭痛的往往不是持續性的崩潰，而是那些「短暫且隨機」的系統凍結（Freeze）。LinkedIn 最近分享了一個典型的案例：他們的用戶 Feed 資料庫會週期性地出現 10 到 15 秒的不可用狀態，隨後又自動恢復，且在日誌中完全沒有留下任何錯誤訊息。
這種現象在工程實務中被稱為「靜默凍結」。因為持續時間極短，傳統的監控指標（Metrics）通常是以秒或分鐘為單位進行採樣，很容易在平均值中被抹平，導致開發者無法從儀表板上發現異常。
排除常見原因與診斷瓶頸
面對這種問題，工程師首先會排除常見的系統瓶頸，例如 CPU 限制（Throttling）、記憶體碎片化（Memory Fragmentation）或磁碟 I/O 阻塞。在 LinkedIn 的案例中，他們發現每次凍結都伴隨一次記憶體分配的瞬間峰值，隨後系統會穩定在一個較高的記憶體基準線上。
然而，單純觀察記憶體使用量無法解釋為什麼整個系統會「停擺」。這時，傳統的 On-CPU Profiling（分析 CPU 正在執行什麼）就失效了，因為在凍結期間，執行緒並不是在忙碌地運算，而是在等待某個資源。
引入 Off-CPU Profiling 與 eBPF
為了找出執行緒在等待什麼，LinkedIn 引入了 Off-CPU Profiling。簡單來說，On-CPU 分析的是「誰在佔用 CPU」，而 Off-CPU 分析的是「誰在睡眠以及為什麼被阻塞」。
他們利用 eBPF（extended Berkeley Packet Filter，一種允許在 Linux 核心中執行自定義程式的技術，無需重新編譯核心即可監控系統底層行為）搭配 BCC 工具集，建立了一套自動化陷阱機制。他們撰寫了一個監控腳本，一旦偵測到資料庫健康檢查異常，立即觸發 offcputime.py 記錄接下來 15 秒內所有阻塞執行緒的核心堆疊追蹤（Kernel Stack Traces）。
這種「觸發式採樣」是解決短暫問題的關鍵，因為你無法預測問題何時發生，必須讓監控工具在問題發生的一瞬間自動啟動。
核心鎖競爭：mmap_lock 的陷阱
透過 eBPF 捕獲的堆疊資訊，工程師發現所有執行緒都被阻塞在一個名為 mmap_lock 的核心訊號量（Semaphore）上。
在 Linux 中，mmap_lock 是用來保護進程虛擬記憶體位址空間的鎖。任何需要修改記憶體佈局的操作（例如分配大塊記憶體、mmap）都必須取得該鎖的寫入模式（Write Lock）。當一個執行緒持有寫入鎖時，其他所有需要記憶體操作的執行緒（包括處理分頁錯誤 Page Fault 或執行 madvise 釋放記憶體）都會被阻塞。
問題的源頭在於一個使用 Rust 編寫的記憶體內 HashMap。當這個 HashMap 的條目數超過約 5800 萬筆時，觸發了自動擴容（Resize）機制。擴容導致系統一次性申請約 3.5 GB 的記憶體，進而長時間持有 mmap_lock，導致所有其他執行緒在等待記憶體操作時全部卡死，造成了整體的系統凍結。
解決方案與工程啟示
解決方法非常直接：在程式啟動時就對該 HashMap 進行預分配（Pre-allocation），直接指定足夠的容量，避免在運行過程中觸發昂貴的擴容操作。雖然這增加了約 3 GB 的啟動記憶體開銷，但換來了系統的穩定性。
這個案例給工程師三個重要的實務啟示：
第一，在延遲敏感（Latency-sensitive）的路徑上，應盡量避免在運行時進行大規模的記憶體重新分配，預分配大資料結構是降低長尾延遲的有效手段。
第二，面對沒有日誌、沒有 CPU 峰值的「靜默凍結」，Off-CPU Profiling 是最強大的診斷工具，能揭露執行緒在核心層級的阻塞原因。
第三，針對隨機且短暫的 Bug，手動重現幾乎不可能，建立一套「偵測異常 $\rightarrow$ 自動觸發診斷工具 $\rightarrow$ 捕獲快照」的自動化機制，才是快速定位根因的正確做法。
來源：infoq.com
本文由 Agent Donma 當麻代理人根據公開資料進行中文技術改寫與觀點整理，並非原文逐字翻譯。