鲲鹏与飞腾平台性能调优：NUMA、绑核与参数对齐实操

国产化替代推进到核心业务系统阶段后，问题从"能不能跑"变成了"跑得好不好"。不少团队把性能不达预期直接归因于 CPU，实际排查下来，相当一部分损耗来自 NUMA 拓扑没摸清、核没绑对、参数照搬 x86 模板。

一、先理解架构差异

• NUMA 划分更细：鲲鹏平台常见每颗 CPU 划分为 4 个 NUMA 节点（对应片上多个 die/簇），跨路访问还有额外开销；飞腾多路平台的节点间距离差异同样明显，跨节点访存延迟可达本地访存的数倍
• 无超线程：鲲鹏主流型号不支持超线程，核数规划要按物理核算
• 内存模型更弱：ARM 采用弱内存序模型，高并发下自旋锁、无锁结构的表现与 x86 不同，更易出现性能抖动

二、先把 NUMA 拓扑摸清楚

• 看节点与距离矩阵：numactl --hardware 输出节点数量、各节点 CPU 与内存容量，以及节点间距离值（本地通常为 10，跨节点更高），距离越大跨节点访存越贵
• 看核与节点的对应关系：lscpu -e 或 lstopo 可看清每个逻辑核归属哪个节点
• 看内存分布是否均衡：若只有一个节点分到大部分内存，说明内存插法或 BIOS 配置有问题，需先在固件层面解决

三、绑核与内存绑定

• 关键进程绑核：用 numactl --cpunodebind=N --membind=N 把数据库、中间件这类长时高负载进程固定在单个节点，让计算与内存同域
• 慎用 interleave：适合内存带宽敏感、能被多节点并行服务的大吞吐场景；对延迟敏感的单实例数据库反而可能变差，需实测
• 中断亲和性：网卡、RAID 卡中断容易集中到少数核并与业务核争抢，建议按队列分散绑定
• 多实例场景：按 NUMA 节点数做实例规划，比让实例自由漂移更稳定

四、编译与运行时

• 优先用已适配的发行版包：自行编译最容易踩的坑是编译选项与实际 CPU 不匹配——要么损失指令集收益，要么在不支持的机器上直接崩
• JVM 参数需要重算：GC 线程数与 NUMA 节点数强相关，建议显式设置 -XX:ParallelGCThreads 与物理核数对齐，并评估 -XX:+UseNUMA；照搬 x86 模板往往线程过多
• 内存分配器：glibc 默认分配器在多 NUMA 下易产生跨节点分配，可用 MALLOC_ARENA_MAX 限制 arena 数量，或评估 jemalloc 后重新压测

五、怎么证明调优有效

不要凭感觉判断"快了"。可用 numastat 观察跨节点分配比例，用 perf stat 对比调优前后的缓存命中与访存指标。更重要的是一条纪律：一次只动一个变量——先绑核，再调运行时参数，最后改应用逻辑，每步都留一份可复现的压测数据。

六、三个常见误判

• 把问题全归给 CPU：瓶颈常出现在内存带宽、中断争抢、存储与网络路径，或编译选项上
• 直接复用 x86 参数模板：数据库、中间件、JVM 的默认值大多按 x86 的核数与 NUMA 形态设计
• 忽略固件与内核版本匹配：升级前应先在非生产环境验证

我们在国产化环境的适配、迁移与性能调优方面有持续实践，可提供平台调优评估与实施支持。