NUMA架构对C#应用的真实影响是跨节点内存访问导致GC延迟升高2–5倍及线程调度抖动；需通过start /NODE命令绑定进程到单个NUMA节点，配合服务器GC、按节点数设堆数、调优线程池，并用ETL+PerfView验证绑定效果。
NUMA 架构对 C# 应用的真实影响在哪？
NUMA（Non-Uniform Memory Access）不是“理论问题”——当你的 C# 应用在 32 核以上服务器、使用大量 ArrayPool<T> 或密集 Span<T> 操作、且内存分配峰值超过 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 隔离 + 手动规划） - 避免使用
SetProcessAffinityMaskAPI 直接调用：.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<string, object>缓存被多节点线程高频写入）
NUMA 优化不是“开个开关就提速”，而是从进程启动、内存分配模式、线程生命周期全程约束——漏掉任意一环，都可能让其他优化归零。
