鲲鹏920与916服务器选型、部署与性能调优实战指南

1. 鲲鹏920与916的核心规格到底怎么理解

1.1 先分清两颗芯片的产品定位

鲲鹏920和鲲鹏916虽然经常被放在一起讨论，但它们在产品线上承担的任务完全不同。我最初接手项目时也犯过嘀咕，以为916就是920的“降频低配版”，用起来才发现两者从设计目标上就是两条路线。

鲲鹏920定位是数据中心旗舰级处理器，面向高性能计算、虚拟化资源池、分布式数据库、大数据分析这类的核心业务负载。它最大的特点就是把核心数堆得很高，配合大内存带宽，适合跑那些“并发线程多、内存访问密集”的业务。我们这边920节点主要跑的是数据库、核心中间件，以及OpenStack的控制节点，属于整个集群里不能出问题的角色。

鲲鹏916的定位则更偏向高能效比的边缘计算、存储节点和管理节点。它的核心数少，功耗低，部署密度可以做得更高，非常适合那种“单台算力要求不高，但节点数量多、总规模大”的场景。我们拿916来做接入网关、日志采集、轻量级容器节点，以及分布式存储的OSD节点，效果比硬塞920划算得多。

一句话总结：920负责扛重活，916负责广覆盖，两者配合才能把集群的性价比做到最优。

1.2 关键参数逐项拆开看

在选型之前，关键参数应该先有一个清晰的对照。我把两颗芯片的公开参数整理成表格，方便大家直接参考：

注意表格里的数值是常见商用规格，具体到不同型号、不同主频档位，还是以华为官方规格书和整机厂商的配置单为准。我在这里想强调的是几个容易被忽略的点。

第一个是内存通道数量。920是8通道DDR4，916是4通道DDR4。这个参数直接影响你能跑出多大的内存带宽，尤其对数据库、内存计算这类负载来说，内存带宽有时候比CPU主频更关键。选配置的时候，双路920至少要把内存插满基本通道，否则带宽优势直接被浪费掉。

第二个是PCIe 4.0。两颗芯片都支持PCIe 4.0，这意味着NVMe SSD、100G网卡、RDMA网卡能跑满带宽。但是，光芯片支持还不够，还需要看整机厂商的主板设计和扩展槽位分配。

第三个是功耗差异。916的功耗只有920的一半左右，在一些对能效比敏感的存储节点和接入节点，这个差距会直接影响机柜功率密度和长期电费。

1.3 规格表里看不出来的三件重要事

除了参数表，我觉得有三件事是规格书里不会明说，但实际使用中一定要知道的。

第一，ARM指令集兼容性不等于软件二进制兼容。鲲鹏920和916都基于ARMv8.2指令集，支持标准的AArch64指令，但指令集支持并不能保证一个在Ubuntu ARM上编译好的二进制就能直接跑到你的openEuler系统里。依赖库、glibc版本、编译器参数都可能成为拦路虎。后面我会专门讲软件适配。

第二，芯片里集成了硬件加速引擎。鲲鹏处理器的加速器包括加密、压缩等能力，比如IPSec、对称加密、无损压缩这类操作可以通过硬件卸载。但问题是，这些加速能力不是默认开启的，需要驱动配合。运维和研发如果不知道这一点，就会白白浪费一颗芯片的隐藏实力。

第三，整机形态决定了最终性能。同样是鲲鹏920，不同厂商做出来的服务器，内存插槽数量、PCIe插槽分配、散热设计和高速互联拓扑都可能不一样。选型不能只看CPU型号，要看整机规格书。

提示：如果你准备做性能对比，请务必把整机配置拉齐，否则CPU、内存、硬盘、网卡任何一个环节都会让评测数据失真。

2. 选服务器时容易踩坑的硬件细节

2.1 内存通道和频率的选择不能妥协

我在部署第一批鲲鹏服务器时就栽过跟头。当时采购单上写的是920双路，结果整机到的是一批只插了4根内存的配置。单看容量好像够用，但8通道只能跑4通道，内存带宽直接腰斩。我们压测数据库时发现，在同样负载下，事务响应时间比预期高出一截，排查半天才发现是内存通道配置的问题。

这里给一个很实际的建议：920双路机器，内存最好按照每路8通道插满，也就是至少16根内存条，再根据容量需求选单条16GB还是32GB。916单路则至少插满4根。如果成本受限，宁可选小容量单条，也要保证通道数量。因为内存通道数量决定了带宽上限，而容量以后还有机会扩。

频率方面同样要注意。整机标称支持2933MT/s，你买3200MT/s内存条也不是不能用，但会被降到2933跑。我建议直接买官方兼容性列表里的内存型号，省得出现不识别或降频的问题。每个整机厂商官网都会有内存兼容性清单，选配置的时候一定让销售按清单下单，这是最容易忽视但最影响稳定性的细节。

2.2 网卡、RAID卡和PCIe设备的兼容性核对

鲲鹏服务器在硬件兼容性上比传统x86平台要敏感得多。很多x86上插上就能用的PCIe设备，在鲲鹏上可能会遇到驱动找不到、固件不兼容、设备识别不稳定等问题。

最常见的坑集中在网卡和RAID卡上。比较成熟的Mellanox网卡、Intel网卡在ARM平台上通常有对应驱动，但你需要下载aarch64版本，不能直接复用x86的rpm包。RAID卡尤其要注意，采购时一定确认厂商是否提供ARM Linux下的驱动，很多廉价RAID卡只提供了x86驱动，插到鲲鹏机器上就是不上盘。

我建议的操作流程是：在项目采购前，先把所有计划使用的PCIe设备列一个清单，然后到整机厂商的兼容性列表里逐一比对，再找测试机把设备装上去用稳定性的方式验证两三天。这一步前置做好，后面交付会省太多精力。

GPU和DPU也要单独说。NVIDIA提供了aarch64架构的驱动，但要注意CUDA版本和驱动版本的配合。需要做人工智能推理业务的话，尽量选用整机厂商兼容性清单里明确支持的GPU型号，否则后面调驱动会非常痛苦。

注意：不要以为“Linux支持”就等于“ARM Linux支持”，更不要觉得“系统能启动”就等于“设备能发挥全部性能”。设备能被识别和能稳定跑满带宽是完全不同的两个层次。

2.3 BIOS版本、固件升级顺序有讲究

鲲鹏服务器交付时，BIOS和BMC/iBMC固件版本往往不是最新版本。我遇到过BIOS版本过旧导致PCIe设备随机掉卡的问题，也遇到过BMC版本没升级导致远程管理界面偶发卡死的情况。所以新机器上架后，第一件事就是做固件基线校准。

原则是先升级带外管理系统固件，也就是iBMC或BMC，然后再升级BIOS，再升级主板CPLD，最后升级RAID卡和网卡固件。这个过程不能打乱顺序，因为BIOS升级可能依赖新的BMC能力，而CPLD负责主板电源时序，出问题可能导致整机无法开机。

升级固件需要的文件包一定要到整机厂商官网对应机型的下载页去获取，不要图省事在搜索引擎里找通用包。当下很多厂商提供了一键升级工具，能自动检查版本并执行升级，但生产环境还是建议先在测试机上跑一遍，确认没有问题后再轮到生产设备。固件升级期间禁止断电，否则主板直接变砖的风险很高。

3. 从x86迁到ARM：软件栈适配的完整清单

3.1 操作系统选型：openEuler还是麒麟

鲲鹏平台支持的操作系统不算少，但选型这件事直接决定后面所有软件包的获取方式和技术支持路径。

openEuler是华为开源的操作系统，也是鲲鹏生态里适配最积极、优化最深入的一个。它提供LTS版本，比如22.03 LTS，生命周期比较长，适合生产环境。我们生产环境用的就是openEuler，原因很简单：软件源里默认就有很多针对鲲鹏优化的包，中间件、数据库、云原生组件都有现成的ARM版本能装。

麒麟V10和统信UOS这两个国内操作系统在信创类项目里很常见，如果你所在的项目有特定的合规要求，可以选它们。它们的软件生态与openEuler大体相通，都基于Linux内核，但包管理工具和源可能不同，具体到某个软件包的版本可能会滞后一点。

Ubuntu和Debian也有完整的aarch64支持，对一些重依赖社区开源软件、想用最新版本的环境比较友好。但从数据中心的长期运维角度看，Ubuntu的非LTS版本升级周期短，给运维带来的压力会大一些。

我这里还有个建议：如果你在评估Windows Server 2016数据中心版这类x86时代的授权模型，就趁早放弃，鲲鹏平台没有官方Windows Server支持路径，也不存在直接把Windows授权套到ARM服务器上的方案。数据中心里的ARM节点应该整体走Linux容器化或开源虚拟化路线。

3.2 编译器、JDK和应用代码迁移

源码迁移是ARM落地最大的工作量来源。x86平台编译出来的二进制程序无法在鲲鹏上运行，这是架构差异决定的事实，所以所有C/C++/Go/Rust代码都需要重新编译，Java代码则相对好办，只要JVM支持aarch64就行。

C/C++代码编译时，建议使用华为提供的毕昇编译器，或者至少用GCC时加上针对鲲鹏的优化参数。比如-march=armv8.2-a，甚至可以尝试-mcpu=tsv110这种针对鲲鹏核的参数。很多项目直接用默认参数编译也能跑，但性能可能差一截，尤其在循环计算和内存访问密集的代码里，差距能到10%以上。

Java环境方面，OpenJDK官方提供aarch64构建，国内常用的是毕昇JDK和阿里Dragonwell。部署时记得加NUMA相关参数，比如-XX:+UseNUMA，这能让JVM更聪明地分配内存线程。我们实际跑压测时发现，同样一台920服务器，开了NUMA的JVM吞吐量比默认模式下高出不少。

具体到代码本身，绝大部分纯Java/Python/Go项目迁移成本很小，最容易翻车的是C/C++项目里使用了x86特有的指令集，比如SSE、AVX这些。这些指令在ARM平台不存在，对应的代码通常需要改写为NEON向量指令，或者找替代的SIMD库。

提示：字节序问题反而不用担心。ARM64在几乎所有服务器场景下都运行在小端模式，和x86一致，所以网络协议、数据文件在迁移时基本不会遇到endian问题。

3.3 容器与虚拟化：镜像是最容易翻车的点

容器化是ARM平台落地的最佳路径，因为应用一旦被打成arm64容器镜像，部署到哪台机器上都是一致的体验。但镜像架构是最大的坑。

Docker官方仓库里大部分镜像都分amd64、arm64等不同架构，如果你在鲲鹏节点上直接docker pull nginx，Docker会自动拉取arm64版本，这个通常没问题。真正的问题出现在公司私有镜像仓库里：里面往往只有x86架构的镜像，部署时直接拉下来跑，结果自然是exec format error。这种报错第一时间就要想到架构不匹配。

解决办法是建立一套多架构镜像构建流水线。使用docker buildx创建多架构构建器，一次构建同时产出linux/amd64和linux/arm64的镜像，并推送到同一tag下。同时，所有基础镜像要选用官方multi-arch版本，或者自己维护arm64基础镜像。

虚拟化层面，KVM在ARM64上是完全可用的，libvirt和QEMU的aarch64支持已经非常成熟。我们用KVM跑Windows和Linux虚拟机都没问题，但注意ARM平台上跑的虚拟机同样是ARM架构，不是x86架构。如果你想在鲲鹏服务器上虚拟化x86虚拟机，那目前无法做到，这是硬边界，选型前要确认业务虚拟机是否也有ARM版本。

Kubernetes集群混部场景，一定给节点打上架构标签，比如kubernetes.io/arch=arm64，然后在工作负载里配置节点亲和性，避免调度器一不小心把arm64镜像调度到x86节点或者反过来。跨架构集群虽然运维复杂一些，却能大大提高硬件利用率的灵活性，值得投入精力。

4. 数据中心上架部署与性能调优实战

4.1 部署架构规划：让920和916各司其职

我们从一开始就规划了一个混合部署方案，核心思路是“重计算上920，轻负载上916”。一个典型的资源池由3台920双路服务器和5台916单路服务器组成，920承载OpenStack控制节点、数据库虚拟机、关键业务容器，916承载接入网关、日志收集、对象存储网关等对单线程性能不敏感的服务。

这样分配后，单机故障影响面更可控。因为916节点上跑的都是无状态服务，挂了直接由集群调度把Pod重新拉起；920节点上跑的关键业务则通过双机热备+数据层多副本保证可用性。

网络规划上，我建议至少划分三类网络：管理网、业务网、存储网。管理网连接iBMC带外管理口，业务网承载应用流量，存储网单独走高性能以太网或RoCE网络。这样做的目的是防止数据备份、业务脉冲、管理信令相互干扰。我们在鲲鹏集群上采用100G RoCE承载存储流量后，备份时间从原来的几小时降到几十分钟。

机柜规划同样不能掉以轻心。920双路的满载功耗不低，如果机柜里还放了交换机和其他设备，单机柜功率密度很容易超过10kW。这时候就需要考虑功率配额和散热设计，别等到跳闸再后悔。

4.2 NUMA感知与CPU绑核，从系统层面榨出性能

ARM多核处理器和x86一样存在NUMA架构，也就是不同的CPU核心访问不同内存区域的延迟不同。如果不做任何配置，操作系统会把内存和线程随意分配，导致很多跨NUMA访问，性能白白损耗。

先用lscpu查看NUMA拓扑结构，再用numactl --hardware查看每个NUMA节点对应的内存范围。部署数据库等内存敏感型应用时，使用numactl --cpunodebind=0 --membind=0方式启动进程，让线程和内存尽量落在同一个NUMA节点。

虚拟机场景下，用virsh vcpupin把虚拟机的vCPU绑定到物理CPU核心，同时设置内存绑定。容器场景稍微复杂一点，Kubernetes默认的CPU管理策略是none，无法保证CPU亲和性。如果想给容器绑核，需要把kubelet的CPU管理策略设置为static，然后把Pod的资源请求和限制设置成相等的整数值，这样Pod会被归类为Guaranteed QoS，并自动绑到核心上。

要提醒的是，绑核不是所有场景都需要。如果应用本身对延迟不敏感，或者部署密度要求高，绑核反而会降低CPU利用率。我们通常只对数据库、中间件、DPDK网卡进程做绑核，其他应用让内核调度器处理就好。

4.3 存储与网络层面的调优细节

存储调优方面，NVMe SSD在鲲鹏平台上能充分发挥PCIe 4.0的带宽优势。挂载时建议加上noatime参数，减少访问时间的写回操作。文件系统方面，XFS在超大文件和大容量场景下表现更稳，所以我更推荐用它做数据盘。

openEuler和很多ARM Linux发行版都支持透明大页，但数据库类应用一般建议关闭透明大页，改用手动配置HugePages。方式是在/etc/sysctl.conf里设置vm.nr_hugepages，比如分配16GB大页可以设置成8192个2MB页。

网络调优的关键是网卡队列。高并发场景下，单队列网卡会成为瓶颈。使用ethtool -L eth0 combined 16把网卡队列扩展到多队列，再配合RSS（接收端扩展）和RPS（接收包控制）机制，让不同CPU核心分摊网络中断处理。我们做网关节点时，这样调完网络吞吐和数据包处理能力都提升明显。

如果业务对网络性能要求更极致，可以考虑DPDK或者OVS-DPDK方案，把数据面从内核态搬用户态。鲲鹏平台对DPDK的支持比较成熟，但一定要给DPDK进程预留CPU核心并配置巨页。这个方案我们只在部分高转发要求场景使用，日常业务其实不需要动这么深。

5. 功耗、散热与液冷：算清楚TCO这本账

5.1 实测功耗数据参考

根据我们机房的实际统计，鲲鹏920双路服务器（配置16根32GB内存、2块NVMe SSD、2块960GB SATA盘、2块25G网卡）的空闲功耗在230W左右，跑满数据库压测时整机功耗会到600W上下。916单路服务器（4根16GB内存、4块HDD、1块25G网卡）空闲大约75W，满载大约220W。

功耗数字会因整机配置不同有波动，但整体趋势很明确：同档位核心数下，鲲鹏平台的功耗并不夸张，能效比是它的加分项。920的双路服务器能做到只比高端x86双路稍高一点的整机功耗，却提供更高的物理核心数。

数据中心的电费核算是按整机功耗乘以实际负载率来算的，不是匀速满载。我们线上节点平均负载率在30%左右时，整机功耗大约只有满载的50%。所以做功耗预算时，一定用业务实际负载率去估算，别拿满负荷数据吓自己。

5.2 风冷到液冷，散热方案怎么选

大部分机房用传统的风冷方案就能解决鲲鹏服务器散热需求，前提是机柜功率密度不要过高。我们机柜功率控制在8kW以内时，采用冷热通道隔离，服务器进风温度不超过25度，节点运行温度一直很平稳。

当机柜功率密度超过15kW以后，风冷的气流组织就难以为继了。这个时候液冷就成了更优选择。液冷的好处很明显：散热效率高，能支持更高的机柜密度；噪音低；还能通过提高冷却液温度来减少制冷系统能耗。

液冷不是买了服务器插上水管就能跑，需要整体规划。冷板式液冷目前比较成熟，通过CDU（冷量分配单元）把冷却液循环到每个节点的冷板上。选型时要关注冷却液类型、管路接口标准、漏液检测方案和CDU的冗余设计。我们在一个高密度机柜里部署液冷节点时，专门增加了漏液传感器，并把传感器连到带外监控系统里，一旦检测到异常立即告警。

对于已有数据中心改造液冷，难度会更大，因为要考虑原有架空地板的承重、管路铺设路径、冷冻水系统对接方式。改造前应做详细的现场勘查和CFD仿真，确认热点区域收益，再决定是整柜液冷还是部分节点液冷。

提示：液冷初投资确实高于风冷，但如果你能把机柜功率密度从8kW提升到20kW以上，省下的机房面积和空调电费通常会在两三年内覆盖液冷的增量成本。

5.3 TCO分析框架，别只看CPU单价

做数据中心建设动态TCO分析时，我最常看到的一个错误就是只对比CPU采购单价，把所有注意力放在芯片价格上。实际上，TCO应该覆盖至少六个模块：

• 硬件成本：整机、网络、存储，包含容灾和备件。
• 功耗成本：IT设备功耗、空调制冷功耗，折算到PUE后才是真实电费。
• 机房空间成本：单位机柜面积的租金或者折旧，高密度部署能摊薄这部分。
• 维保成本：原厂维保、备件库、技术支持人力。
• 软件许可成本：很多商业软件按CPU颗数或者按物理核心收费，迁移到ARM平台可能涉及新的许可证策略。
• 迁移人力成本：应用重构、测试、双轨运行期间的人力投入。

拿实际案例来算：假设单台920节点替换同档位x86节点，硬件价格差放在一边，如果功率低20%，按每千瓦时1元电费、全年8760小时、平均功率450W计算，一年省下的电费大约是450乘以0.2乘以8760除以1000，也就是788.4元。如果集群里有一百台这样的节点，一年就是7.8万电费，这个数字看起来不算夸张，但乘以设备五年生命周期就是接近40万。

TCO分析最关键的是模型要贴合自己的业务负载。同样一台服务器，跑搜索业务的功耗曲线跟跑数据库完全不一样，所以最好的做法是先在一个测试节点上跑一周真实业务采样数据，再代入TCO公式计算。

6. 运维监控与日常管理的经验

6.1 监控体系建设：带外和带内两条腿走路

鲲鹏服务器的日常运维，一定要做到带外管理和带内监控两条线并行。带外管理走BMC/iBMC口，即使操作系统完全崩溃也能远程开机、关机、查看硬件健康状态。我们通过ipmitool -I lanplus -H <带外IP> -U <用户名> -P <密码> sdr list可以批量获取节点温度、风扇转速、电源状态等信息。比如风扇转速过高会直接影响噪音和功耗，通过带外监控就能第一时间发现。

带内监控跑在操作系统里，采集的是CPU使用率、内存利用率、IO延迟这些应用视角的数据。最常用的组合是Prometheus + node_exporter + Grafana。node_exporter在ARM64 Linux下可以直接下载对应二进制，部署方式和x86没区别。我们还会给数据库和中间件部署额外的exporter，比如MySQL exporter、Redis exporter，确保从应用到硬件每一层都有数据。

告警阈值需要根据实际机型调整。ARM平台的温度阀值和功耗模型和x86不完全一样，直接用x86的阈值规则可能导致误报或漏报。我们先跑了两个月基线数据，再根据P95值设定告警线，比如CPU温度超过80度预警，85度告警，内存ECC错误累计超过一定次数就自动创建工单。

6.2 固件与补丁管理，该建台账就建台账

集群规模大了以后，固件版本管理如果还靠脑子记，迟早出事。我们内部建立了一个配置基线台账，每台机器记录以下关键项：iBMC固件版本、BIOS版本、CPLD版本、RAID卡固件版本、网卡固件版本、操作系统版本和内核版本。

每次重大变更前，先检查配置基线台账，确认目标版本和现有版本的差异。升级固件必须走变更流程：测试机验证、生产环境单台灰度、再批量升级。我遇到过一次性把整个集群固件升级到最新版本，结果新BIOS和安全软件冲突导致部分节点重启后内存频率异常，最后只能逐台回退。从那以后，我再也不做无脑批量升级了。

补丁管理方面，openEuler的软件源会不定期推送安全补丁，尤其是内核和QEMU虚拟化组件的补丁，建议在测试环境回归后再批量推到生产。内核升级后要重启，所以尽量把节点分批重启，避免集群出现大规模服务中断。

6.3 IT运维体系向ARM双栈演进的经验

现在不少数据中心的现状是x86存量集群和ARM新生集群并存，这也被称作双栈架构。双栈运维的痛点是两套架构的命令习惯、软件包格式、故障排查思路都有差异。运维人员如果只懂x86，遇到ARM节点出问题往往会用错排查方向。

我建议团队内部建立一本软件兼容性台账，给每一个应用记录架构、版本、依赖、部署方式和验证状态。比如某个Java服务在x86上跑3.2.1版本没问题，ARM上是否同样验证过，用的哪个JDK版本，这些都要记录下来。这样新员工接手，不用从零摸索。

自动化运维工具也需要做架构适配。Ansible、SaltStack这类工具本身支持ARM节点管理，但playbook里如果写了yum install某些仅x86架构的包，就会失败。所以自动化脚本里的软件包名或架构标签必须显式声明，比如ansible_architecture == "aarch64"和ansible_architecture == "x86_64"分条件执行。

我还想提一点，数据中心运行与管理相关专业的工程师，如果能深入理解硬件、系统、应用这三层适配关系，在双栈环境里会非常有竞争力。因为ARM平台的问题往往不是单一层面的，比如一个数据库查询慢，可能SQL本身没问题，是JVM没开NUMA优化，再往底层可能是CPU核心绑得不合理。这种从应用一路追到硬件的综合排查能力，才是ARM数据中心落地中最稀缺的。

在我自己使用鲲鹏平台的过程中，最大的体会是它并不是“拿过来就能用”的平台，也不是“性能不行”的平台，而是需要你花时间理解它、适配它。一旦把硬件配置、软件栈、运维工具都调整到合适状态，920和916组成的资源池在处理大规模并发、虚拟化整合和能效比方面的表现确实值得投入。如果你也正准备在数据中心里引入鲲鹏节点，建议从一个小规模的验证集群开始，把上面这些环节跑通再扩大规模。