安德魯的部落格

.NET Core 跨平台 #2, 記憶體管理大考驗 - setup environment

Summary 查看原始文章

.NET Core 跨平台 #2, 記憶體管理大考驗 - setup environment

摘要提示

  • 記憶體管理與平台: 記憶體管理高度依賴底層平台，開發者能直接掌控的只在配置/釋放與理解 GC 機制上。
  • 跨平台驗證動機: .NET Core 開源且支援 Linux/MacOS，提供實測不同平台記憶體行為的機會。
  • 測試目標: 透過製造記憶體碎片檢驗 GC 與 .NET Core runtime 在記憶體不足下的表現與保護性。
  • 三階段測試法: 先連續配置 64MB 直到 OOM，再釋放偶數塊造成碎片，最後嘗試配置 72MB 直到 OOM。
  • 對照與延伸: 以傳統 .NET 環境作對照組，並預計後續上 Azure 做整體評比。
  • 環境隔離: 使用 Hyper‑V 建立多個相同規格 VM，單次只啟一台避免干擾。
  • 平台組合: 測試包含 Boot2Docker、Ubuntu+Docker、Windows Server 2012 R2、Windows Server 2016 TP4 (Nano+Windows Container)。
  • 硬體配置: 主機 i7-2600K、24GB RAM、SSD+企業級 HDD，VM 固定 1 vCPU/1GB RAM/4GB Swap。
  • 測試程式設計: 以 C# 建立三段配置/釋放流程，記錄可配置數量與耗時。
  • 寫入初始化: 新增 InitBuffer 以亂數填滿配置後的 byte[]，避免「懶配置/壓縮」等影響，讓測試更接近實際佔用。

全文重點

本文聚焦於 .NET Core 在不同平台上的記憶體管理行為，並以實測驗證 GC 與 runtime 在高度碎片與記憶體不足情境下的韌性與效能。作者指出，記憶體管理深受底層系統影響，開發者能直接介入的多為配置與釋放，以及盡可能理解與配合 GC；超出範疇時只能妥善處理例外。隨著 .NET Core 開源並支援 Linux 與 macOS，作者重提過往記憶體碎片議題，將同一測法移植到新平台比較差異。

測試方法分三步：第一，連續配置 64MB 區塊直到 OOM，記錄總數與耗時；第二，保留奇數塊、釋放偶數塊並手動觸發 GC，藉此製造碎片，使記憶體難以再容納超過 64MB 以上連續空間；第三，再嘗試配置 72MB 直到 OOM，測量可配置數與時間，以觀察碎片化後的可用性與 runtime 壓力處理能力。此設計旨在檢視 GC 是否能合併回收、是否受到大型物件堆 (LOH) 或平台配置策略影響，以及在壓力下對應用程式的保護是否恰當。

為求可控與可比，作者在自己的 PC 上以 Hyper‑V 建立多台規格相同的 VM，僅單台啟動進行測試，避免背景干擾。測試平台含 Docker 型 Linux（Boot2Docker、Ubuntu 15.10+Docker）、純 Windows（2012 R2 直跑 .NET Core）、以及 Windows 2016 TP4 的 Windows Container（Nano 主機上跑 windowsservercore 容器再安裝 CoreCLR）。此舉除比較 OS 與容器差異，也預視 Windows Container 的可行性，惟版本為技術預覽僅供參考。雲端版本將待下篇圓周率計算測試完成後，一併上 Azure 做整體評比。

硬體/VM 配置方面，主機為 i7-2600K、24GB RAM、SSD 搭配企業級 HDD；VM 統一 1 vCPU、1GB RAM（關閉動態記憶體）、4GB Swap、32GB VHDX，確保測試條件一致。程式碼以 C# 撰寫，流程明確記錄每階段可配置區塊數與執行時間。特別之處在新增 InitBuffer：對新配置的 byte 陣列以亂數填滿，避免僅「保留位址未實佔用」帶來的假性成功或記憶體壓縮策略差異，使測試更貼近真實佔用下的行為。本文為系列第 2 篇，著重於測試環境與方法建立，並預告後續結果分析；作者也坦言過程中發現多處出乎意料的現象，結論不會只是簡單的肯定或否定。

段落重點

前言與動機

作者強調記憶體管理與底層平台緊密相關，開發者的可控面向有限，實務上多仰賴 GC 與正確釋放，以及面對 OOM 時的例外處理。因 .NET Core 跨平台與開源帶來新契機，作者將過往對記憶體碎片議題的老測法移植至新平台比對，認為實測是掌握差異的最快方式。文章定位為系列的一部分，專注於搭建測試環境與方法，並預告後續會把實測搬上 Azure 做綜合評估。

測試的方法

測試規劃明確：1) 連續配置 64MB 區塊至 OOM，量測可配置數與耗時，建立基線；2) 釋放偶數區塊並觸發 GC，刻意製造碎片，使可用空間難以形成超過 64MB 的連續區段；3) 嘗試配置 72MB 區塊至 OOM，以驗證 GC/Runtime 是否能應對碎片、是否具備合併或壓縮能力，以及在壓力下對應用程式的穩定性與保護性。此方法可觀察大型物件堆行為、不同 OS/容器下配置策略差異與效能影響。作者指出結果會有出乎意料之處，顯示議題複雜度高於直覺。

測試環境與平台

為確保可重現與隔離影響，作者以 Hyper‑V 建多台相同規格 VM，單次只啟動一台。主機 i7-2600K/24GB，VM 統一 1 vCPU、1GB RAM（停用動態記憶體）、4GB Swap、32GB VHDX。平台涵蓋：Boot2Docker（Docker Toolbox 1.9.1）、Ubuntu 15.10+Docker 1.9.1、Windows Server 2012 R2（直接跑 .NET Core）、Windows Server 2016 TP4（Nano 作宿主、建 windowsservercore 容器內安裝 CoreCLR）。Windows Container 為技術預覽，結果僅供參考。雲端部分計劃與圓周率測試一併上 Azure 比較。

#0. 準備測試程式

C# 測試程式分三段：先以 64MB 連續配置直至 OOM；再清掉偶數塊清單並觸發 GC 造成碎片；最後連續配置 72MB 直至 OOM。每段記錄配置數與時間，最後彙總總配置量。程式核心在以 List<byte[]> 持有區塊，透過清單 Clear 與 GC.Collect 釋放偶數塊參考。新增的 InitBuffer 對新配置的陣列做亂數填充，避免僅虛擬保留導致的「看似成功但未實際佔用」情況，使測試反映真實物理/頁面承載壓力。作者以此程式作為跨平台一致的測量工具，為後續分析鋪路，並表示內容未完待續。

資訊整理

知識架構圖

  1. 前置知識：
    • 基本 .NET/.NET Core 觀念：託管記憶體、陣列配置、例外處理
    • GC 基礎：代際回收、壓實(compaction)、大物件堆(LOH)特性與碎片化
    • 作業系統記憶體管理：虛擬記憶體、實體配置/承諾(commit)、頁面配置、OOM
    • 容器/虛擬化：Hyper-V、Docker、Linux/Windows Container 基本概念與資源限制
  2. 核心概念：
    • 記憶體碎片化：交錯釋放造成的大塊連續空間不足，影響大型區塊配置
    • GC 與 LOH 行為：LOH 不一定壓實，易受碎片化影響；GC 代際與手動觸發的限制
    • 跨平台差異：.NET Core 在 Windows/Linux/Container 上的配置策略與 OOM 保護差異
    • 測試方法學：可重現的步驟、控制變因、以實測驗證平台差異
    • 實際觸發配置：寫入初始化(InitBuffer)確保實際記憶體承諾，避免過度配置假象
  3. 技術依賴：
    • .NET Core Runtime/CoreCLR 依賴 OS 記憶體管理與容器/VM 提供的資源
    • Docker/Container 依賴宿主 OS/Hyper-V，資源限制會影響 GC/OOM 行為
    • 測試程式依賴標準庫(System, 集合類別)與 GC API(GC.Collect)
  4. 應用場景：
    • 高記憶體占用服務：影像/資料處理、快取服務、資料庫代理
    • 容器化部署：需預估與限制記憶體，避免 OOMKill 或服務不穩
    • 跨平台移植評估：比較 Windows/Linux/Container 上的記憶體行為與穩定性
    • 效能/可靠度測試：壓力測試、碎片化容忍度、GC 調校驗證

學習路徑建議

  1. 入門者路徑：
    • 了解 .NET 託管記憶體與 GC 基礎（含 LOH）
    • 能閱讀並執行示例程式：連續配置、交錯釋放、手動 GC
    • 認識虛擬記憶體與 OOM 的基本概念；學會觀察程序記憶體使用
  2. 進階者路徑：
    • 研究跨平台差異（Windows vs Linux）與容器資源限制對 GC 的影響
    • 實作與比較 InitBuffer 有/無初始化的差異（觸發實際承諾）
    • 使用監測工具（perf counters、dotnet-counters、perf/Procfs、Windows Performance Monitor）
  3. 實戰路徑：
    • 以相同 VM/Container 規格建立可重現測試環境（Hyper-V、Docker）
    • 自動化量測流程：多平台跑相同測試、收集配置數、耗時、OOM 情況
    • 擴展到雲端（如 Azure）：納入雲端計費/限制、部署方式、觀測與告警

關鍵要點清單

  • 測試三步驟設計：64MB 連續配置→釋放偶數塊→72MB 再配置，用以製造碎片並驗證可用大塊空間 (優先級: 高)
  • LOH 與碎片化：大物件堆多半不壓實，易在交錯釋放後造成無法配置更大區塊 (優先級: 高)
  • GC.Collect 限制：手動觸發 GC 不等同於消除碎片，尤其在 LOH 堆上效果有限 (優先級: 高)
  • InitBuffer 的必要性：寫入隨機資料確保頁面實際承諾，避免虛擬過度配置掩蓋問題 (優先級: 高)
  • OOM 行為觀察：不同平台/容器在接近 OOM 時的保護與失效模式可能不同 (優先級: 高)
  • 跨平台比較：Windows、Linux、Windows Container 的 .NET Core 記憶體配置策略與限制各異 (優先級: 高)
  • 容器資源限制：Docker 記憶體/Swap 限制會顯著影響 GC 表現與 OOM 時機 (優先級: 中)
  • 測試環境一致性：統一 VM 規格（CPU、RAM、Swap、磁碟）是客觀比較的前提 (優先級: 中)
  • 動態記憶體關閉：Hyper-V 停用動態記憶體避免干擾測試結果 (優先級: 中)
  • 監控與度量：記錄配置數、耗時與例外，並搭配系統監控工具交叉驗證 (優先級: 高)
  • 程式設計可控面：開發者能控制的是配置模式與釋放時機、異常處理，而非底層分配器 (優先級: 中)
  • 大塊配置風險：長時間服務中反覆大塊配置/釋放會放大碎片化風險 (優先級: 高)
  • 平台成熟度：技術預覽（如 Windows 2016 TP4 Container）結果僅供參考，需待正式版複測 (優先級: 低)
  • 雲端再驗證：本地與雲端（Azure）因超賣與限制策略差異，需二次驗證 (優先級: 中)
  • 實務建議：若需大量大物件，考慮自管池化、減少交錯釋放、避免頻繁巨大陣列 (優先級: 高)




Facebook Pages

AI Synthesis Contents

- 原始文章內容
- 問答集
- 文章摘要
- 解決方案 / Case Study

Edit Post (Pull Request)

Post Directory