NUMA 架构对 C# 应用的真实影响在哪？
NUMA（Non-Uniform Memory Access）不是“理论问题”——当你的 C# 应用在 32 核以上服务器、使用大量
ArrayPool<t></t>或密集
Span<t></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></string>缓存被多节点线程高频写入）
NUMA 优化不是“开个开关就提速”，而是从进程启动、内存分配模式、线程生命周期全程约束——漏掉任意一环，都可能让其他优化归零。
