c# NUMA 架构和 C# 应用的性能调优

NUMA架构对C#应用的真实影响是跨节点内存访问导致GC延迟升高2–5倍及线程调度抖动；需通过start /NODE命令绑定进程到单个NUMA节点，配合服务器GC、按节点数设堆数、调优线程池，并用

ETL+PerfView验证绑定效果。

NUMA 架构对 C# 应用的真实影响在哪？

NUMA（Non-Uniform Memory Access）不是“理论问题”——当你的 C# 应用在 32 核以上服务器、使用大量 ArrayPool 或密集 Span 操作、且内存分配峰值超过 64GB 时，跨 NUMA 节点访问内存会直接导致 GC.Collect() 延迟升高 2–5×，ThreadPool 工作线程调度抖动明显。Windows 默认不绑定进程到特定 NUMA 节点，.NET 运行时也不自动感知拓扑，这意味着你写的高性能服务可能正默默承受非本地内存访问的惩罚。

如何让 .NET 进程绑定到单个 NUMA 节点？

不能靠 Process.PriorityClass 或 Thread.BeginThreadAffinity() 解决——它们不控制 NUMA 亲和性。必须在进程启动前由操作系统层完成绑定：

• 使用 Windows 自带的 start /NODE 命令启动应用：

  start /NODE 0 /AFFINITY 0x000000FF MyService.exe

  （其中 0x000000FF 是 CPU 掩码，对应节点 0 的前 8 个逻辑核）
• 在容器中（如 Windows Server Container），通过 --cpuset-cpus + --memory 组合限制，但需确认宿主机启用了 numactl 兼容层（Windows 容器目前不原生支持 numactl，需改用 Hyper-V 隔离 + 手动规划）
• 避免使用 SetProcessAffinityMask API 直接调用：.NET 6+ 的 Environment.ProcessId 在容器中可能返回不准确 PID，导致设置失败

ThreadPool 和 GC 在 NUMA 场景下的关键配置

.NET 默认的线程池和 GC 行为假设内存访问代价均等，这在 NUMA 下失效：

• 启用 ThreadPool.UseLegacyExecutionContextFlow（false）无意义——它只影响 ExecutionContext 流转，不改变线程物理位置
• 必须设置环境变量 DOTNET_gcServer=1（启用服务器 GC），否则工作站 GC 会在每个线程栈分配本地内存，加剧跨节点指针引用
• 推荐显式设置 DOTNET_gcHeapCount = NUMA 节点数（例如 4），让 GC 为每个节点维护独立堆段，减少跨节点 Gen2 扫描压力
• ThreadPool.MinThreads 不建议设为核数 × 2——应按 NUMA 节点内逻辑核数设置，比如节点 0 有 12 核，就调用 ThreadPool.SetMinThreads(12, 12)

验证 NUMA 绑定是否生效的三个硬指标

光看任务管理器“CPU 使用率”没用。要确认绑定成功，必须检查：

• 运行 logman query -ets && logman start "NumaNodeTrace" -ets -o numa.etl -nb 16 16 -bs 1024 -f bincirc -cnf 00:05:00，再用 perfview /accepteula Collect /CircularMB:512 /KernelEvents:Process+Thread+VirtualAlloc+VirtualFree 抓取 30 秒，打开后查看 VirtualAlloc 的 Node 列是否稳定为单一值
• 在代码中读取 Windows.Win32.System.SystemInformation.GetNumaHighestNodeNumber（P/Invoke），再对比 GetCurrentProcessorNumberEx 返回的 GROUP_AFFINITY 中的 NodeNumber 字段
• 监控 .NET CLR Memory\% Time in GC 计数器：绑定后若仍长期高于 8%，说明仍有跨节点对象引用（比如共享的 ConcurrentDictionary 缓存被多节点线程高频写入）

NUMA 优化不是“开个开关就提速”，而是从进程启动、内存分配模式、线程生命周期全程约束——漏掉任意一环，都可能让其他优化归零。