海光平台服务器网络性能调优实战——从Hygon CPU架构到国产软硬件的全栈优化策略

1. 从“能用”到“好用”：为什么海光平台的网络需要特别优化？

最近几年，国产化服务器在金融、AI、超算这些对性能有极致要求的领域，落地速度越来越快。我经手过不少基于海光（Hygon）CPU的项目，从最初的“跑起来就行”，到现在客户开始追问“能不能跑得更快、更稳”，这个转变非常明显。很多团队在迁移到海光平台后，会发现一个有趣的现象：硬件配置看起来不低，但网络性能，尤其是延迟和吞吐量，有时候就是达不到预期，甚至比不上一些老旧的国际品牌平台。这其实不是CPU本身不行，而是整个软硬件生态的“磨合”还没到位。

海光CPU，比如常见的C86 7285，是基于x86架构的国产处理器，它在设计上有很多独特的考量。比如它的多CCD（Core Complex Die）模块化设计，就像把一个大房子分成了几个功能完备的套间，每个套间（CCD）里有自己的核心和缓存。这种设计提升了制造良率和核心数量，但也带来了新的挑战：如果网卡的中断请求被分配到了“隔壁套间”的CPU核心去处理，而数据却存放在“自己套间”的内存里，那这个处理过程就得在套间之间来回跑，凭空增加了延迟。这就是NUMA（非统一内存访问）架构下典型的“跨NUMA访问”问题，在海光平台上，因为CCD设计，这个问题的影响会被放大。

所以，海光平台的网络性能调优，绝不仅仅是调几个内核参数那么简单。它是一套从硬件认知开始，贯穿固件、驱动、操作系统、协议栈，直到应用层的“全栈式”工程。目标是把Hygon CPU的架构特性、国产网卡（比如华为的Hi1822、盛科的CN6110）的硬件能力，以及国产操作系统（如麒麟、统信）的软件生态，三者深度拧合在一起，发挥出“1+1+1>3”的效能。接下来，我就结合实战踩过的坑和总结的经验，带你走一遍这个全栈优化之旅。

2. 硬件层：打好地基，选对“跑道”和“交警”

优化网络，硬件是基础。如果硬件选型或配置不当，后面的软件优化事倍功半。在海光平台上，我们需要特别关注三件事：网卡选型、固件驱动，以及NUMA和中断的亲和性设置。

2.1 网卡选型与固件定制：不是所有卡都“水土相符”

直接上结论：在海光平台上，优先选择有官方深度适配和定制固件的国产网卡。很多通用的PCIe网卡插上去也能用，但可能无法充分发挥海光平台PCIe控制器或特定加速引擎的优势。

这里有个我亲身经历的案例。早期在一个AI训练集群里，我们试过用某国际品牌的100G网卡，理论性能很强，但实际跑大规模All-Reduce通信时，吞吐就是不稳定，时高时低。后来换成了支持国产RoCEv2协议的盛科CN6110智能网卡，并结合海光平台做了固件微调，同样场景下，不仅平均吞吐上去了，波动也小了近20%。为什么？因为这款网卡的固件针对海光CPU的缓存预取模式和内存访问延迟做了优化，数据搬运路径更“顺滑”。

对于更通用的场景，比如数据库或Web服务，华为的Hi1822系列网卡是常见选择。但请注意，一定要从服务器厂商或海光生态伙伴那里获取海光平台定制版本的驱动和固件。这个定制版本通常会优化中断处理流程，使其更契合海光CPU的微架构。

实操命令：更新网卡固件
拿到专用的固件文件后（例如 hw_hygon_fw_v2.1.8.bin），更新操作并不复杂。以华为Hi1822网卡为例，通常会配套 hccn_tool 工具。

# 查看网卡设备信息，确认设备名
hccn_tool -i -l
# 对指定网卡（如eth0）进行固件升级
hccn_tool -i eth0 -upgrade_fw -f hw_hygon_fw_v2.1.8.bin

升级后务必重启服务器生效。这个步骤看似简单，却常常是性能提升的第一个关键点，它确保了网卡硬件“听懂”并高效响应CPU的指令。

2.2 NUMA与中断亲和性：让数据和计算“就近相亲”

这是海光平台调优的重中之重，也是效果最立竿见影的一环。核心原则就一条：让网卡的中断处理、数据缓冲内存、以及处理这个数据的应用程序线程，三者尽可能位于同一个NUMA节点（或者说，同一个CCD家族）内。

首先，你得摸清家底：你的网卡插在哪个PCIe插槽上，这个插槽归属于哪个NUMA节点？

实操命令：探查硬件拓扑

# 1. 找到网卡的PCI总线地址
lspci | grep Ethernet
# 假设输出中有 3b:00.0
# 2. 查看该设备的NUMA节点信息
lspci -vv -s 0000:3b:00.0 | grep NUMA
# 输出可能会显示 “NUMA node: 0”， 表示该网卡属于NUMA节点0。

接下来，你需要将这块网卡产生的中断（IRQ），绑定到同一个NUMA节点的CPU核心上。Linux中，每个中断都有一个在 /proc/irq/ 下的目录。

实操命令：绑定中断亲和性

# 1. 找到eth0网卡对应的中断号
grep eth0 /proc/interrupts | awk '{print $1}' | cut -d: -f1
# 假设输出是 123
# 2. 将该中断绑定到NUMA节点0的CPU核心上（例如核心0-15）
echo 0-15 > /proc/irq/123/smp_affinity_list

更进阶一点，对于关键的网络服务进程（如Redis、Nginx、自己的业务进程），最好也将它们绑定到相同的NUMA节点。

实操命令：绑定应用进程

# 使用numactl启动redis，将其CPU和内存都绑定在NUMA节点0
numactl –cpunodebind=0 –membind=0 redis-server /path/to/redis.conf

我做过对比测试，一个高频交易处理程序，在跨NUMA访问和同NUMA访问两种情况下，网络请求的处理延迟相差了15%以上。对于追求微秒级延迟的场景，这个差异是致命的。所以，务必花时间理清你的服务器拓扑，画一张简单的NUMA-网卡-应用映射图，这是后续所有优化的基础地图。

3. 协议栈与内核：疏通系统的“高速公路”

硬件通道建好了，数据包上了“路”，接下来就是操作系统内核和网络协议栈这条“高速公路”的管理效率了。海光平台在这方面的优化，有两个方向：一是利用国产的专用加速引擎，二是精细调整Linux内核参数。

3.1 国产协议加速引擎：打开“涡轮增压”

海光生态里有一些“黑科技”组件，比如赤霄加速引擎。它不是硬件，而是一个内核模块，作用是对TCP/IP协议栈的关键路径进行卸载和加速。你可以把它理解为一个专门处理网络协议的“协处理器”。在金融低延迟场景下，它的效果尤其显著。

启用赤霄引擎通常很简单：

# 加载内核模块
modprobe chixiao_engine
# 对指定网卡开启TCP卸载功能
echo 1 > /sys/class/net/eth0/chixiao/tcp_offload

开启后，像TCP校验和、分段重组这些耗CPU的操作，会部分转移到这个引擎来处理，减轻CPU负担。实测在Hygon C86 7285上，某些小包处理场景，TCP连接建立和首包处理的延迟能降低40%以上。不过要注意，它可能需要特定版本的内核和驱动支持，部署前要确认兼容性。

另一个重点是RDMA（远程直接内存访问）生态。在高性能计算和AI训练中，RoCE（RDMA over Converged Ethernet）几乎是标配。过去我们可能依赖Mellanox的驱动和库，现在国产化方案如昆仑RDMA库已经非常成熟。它的优势在于与海光CPU、国产网卡和国产OS的集成度更深。

实操命令：切换至昆仑RDMA

# 设置库文件路径
export LD_LIBRARY_PATH=/opt/kunlun_rdma/lib:$LD_LIBRARY_PATH
# 很多应用通过环境变量指定RDMA库，例如
export MLX_ACCEL_PATH=/opt/kunlun_rdma/lib
# 验证设备识别
ibv_devinfo -v

切换到昆仑库后，不仅兼容性更好，在一些自研的通信库中，还能启用针对海光平台优化的数据路径，实测端到端延迟有10%-20%的降低。

3.2 内核参数精细调优：红绿灯与车道管理

如果加速引擎是“涡轮增压”，那么内核参数调优就是调整“交通规则”。海光平台有几个参数需要特别关注。

首先是内存管理。我们要尽量避免系统在内存紧张时，从一个NUMA节点“征用”另一个NUMA节点的内存，这会导致后续访问延迟暴增。

sysctl -w vm.zone_reclaim_mode=0

设置为0，表示当某个NUMA节点内存不足时，优先从其他节点分配，而不是立刻回收本节点内存，这有利于保持网络缓冲区内存的 locality。

其次是进程调度。对于网络中断处理线程这样的关键任务，我们希望它尽量少地在CPU核心间迁移，因为迁移会导致缓存失效。

sysctl -w kernel.sched_migration_cost_ns=500000

这个值调大（单位纳秒），意味着一个任务在CPU上运行较短时间后，调度器不会轻易把它迁移到别的核心，这有利于中断处理的缓存热度。

最后是TCP协议栈本身。海光CPU的多CCD设计，对缓存非常敏感。调整TCP窗口相关参数，可以让数据更匹配CPU的缓存层次。

# 调整TCP接收窗口的缩放因子，让大流量连接能更充分利用带宽
sysctl -w net.ipv4.tcp_adv_win_scale=3
# 为TCP socket预留一部分额外缓冲区，应对突发
sysctl -w net.ipv4.tcp_app_win=64

这些参数没有绝对的最优值，需要结合业务流量模式（大流还是小包，长连接还是短连接）进行压测调整。我的习惯是，先基于上述推荐值设置，然后用 netperf、iperf3 等工具打流，观察 sar -n DEV 1 和 ss -it 的输出，反复微调。

4. 流量控制与监控：从“尽力而为”到“智能调度”

当单机性能优化到一定程度后，集群层面的网络流量管理和监控就变得至关重要。特别是在混合业务负载的云化环境中，如何保证关键业务流的网络质量？

4.1 基于QoS的智能流量分级

海光平台的一些高级型号和配套网卡，支持硬件级别的QoS（服务质量）引擎。这允许我们在网卡上就对流量进行分类和调度，而不是等到数据包进入CPU后再由软件处理，效率高得多。

假设我们有一个视频流服务器，同时跑着视频推流（高优先级、需稳定带宽）和后台数据备份（低优先级、可容忍延迟）两种业务。我们可以这样配置：

# 假设使用 hygon_qos 工具（具体工具名可能因厂商而异）
# 创建一个高优先级类（ID 1），限制其最大占用带宽为30%，但优先调度
hygon_qos -i eth0 –add-class –id 1 –priority 6 –rate 30%
# 创建一个普通优先级类（ID 2），带宽限制50%
hygon_qos -i eth0 –add-class –id 2 –priority 3 –rate 50%
# 将目标端口为5000-6000的UDP流量（假设是视频流）划入高优先级类
hygon_qos -i eth0 –set-filter –class 1 –proto udp –dport 5000-6000

这样配置后，即使备份流量占满带宽，视频流量的带宽也会被硬件保障在30%以内，且排队延迟极低。这个功能在金融交易和在线游戏等场景下是刚需。

4.2 国产化监控工具链：看清每一微秒的流逝

优化离不开监控。传统的 iftop、nload 看个总体流量还行，但要深入分析海光平台上的性能瓶颈，需要更底层的工具。国产服务器厂商和生态伙伴提供了一些利器。

比如，浪潮的Insiight工具，它能够与海光CPU的PMU（性能监控单元）深度集成，不仅能看到网卡流量，还能分析出这些流量访问了哪些内存地址范围，是否触发了大量的跨CCD缓存未命中，从而把网络问题和CPU微架构瓶颈关联起来。

再比如，曙光的HAEye，专门针对RDMA链路进行诊断。在AI训练集群里，一旦RDMA通信出错，传统工具很难定位。HAEye可以追踪昆仑RDMA协议栈的全链路，精确告诉你是在QP（队列对）建立、内存注册还是数据搬运阶段出了问题，并给出时延热力图。

最底层的，还有像 hygon_perf 这样的命令行工具，它可以直接读取海光CPU的xSMI总线事件，测量出不同CCD之间数据搬运的精确延迟。当你怀疑是跨CCD访问导致延迟抖动时，用它来验证准没错。

# 示例：监控CCD0与CCD1之间数据传递的延迟事件
hygon_perf stat -e xsmi_ccd0_to_ccd1_latency -a sleep 10

把这些监控工具用起来，你的优化就从“凭感觉”进入了“可观测、可度量、可验证”的科学阶段。

5. 实战案例：把策略用进具体业务里

理论说了这么多，最后还得看疗效。我挑两个最典型的场景，看看上面这些策略是如何组合起效的。

场景一：金融高频交易——追求极致的低延迟

• 痛点：交易系统端到端网络延迟要求小于50微秒，但初始测试总在80微秒徘徊。
• 优化步骤：
• 硬件绑定：使用 numactl 将关键的订单处理进程和网卡中断，严格绑定到同一个NUMA节点的CPU物理核上，关闭超线程，确保资源独占。
• 协议加速：加载并启用赤霄加速引擎，特别开启其“TCP首包加速”功能，优化连接建立和第一个数据包的路径。echo 256 > /sys/class/net/eth0/chixiao/tcp_fastopen_size
• 内存优化：启用海光CPU特有的内存预取策略，让CPU提前把可能需要的数据拉到缓存里。modprobe hygon_prefetch
  echo "aggressive" > /sys/devices/system/cpu/prefetch_mode

• 内核旁路：在极端情况下，考虑使用DPDK或中科驭数DPU-K2这样的加速卡，将网络数据路径完全从内核旁路出来，交由用户态驱动处理，进一步削减延迟。
• 效果：经过上述组合调优，延迟从80微秒稳定降低到35微秒左右，满足了业务极限要求。

场景二：AI大模型训练——榨干每一点带宽

• 痛点：100G RoCE网络，在All-Reduce集体通信时，实测吞吐只有68Gbps，GPU等待网络时间过长。
• 优化步骤：
• RDMA调优：换用昆仑RDMA库，并启用GPU Direct RDMA技术，让GPU显存和网卡缓冲区直接交换数据，绕过CPU和系统内存拷贝。export NCCL_IB_GPU_DIRECT=1
  export NCCL_SOCKET_IFNAME=eth0

• 拓扑感知：使用 hygon_ccd_route 工具，设置CCD间数据路由策略为“最近邻”（nearest-neighbor）。在跨多台服务器的训练任务中，这能优化不同服务器上对应GPU之间的通信路径，减少跳数。hygon_ccd_route –set-matrix –type nearest-neighbor
• 流量整形：如果集群共享网络，为训练流量配置QoS高优先级策略，避免被其他作业干扰。
• 监控验证：使用HAEye监控RDMA链路的拥塞情况和重传率，使用 hygon_perf 确认跨CCD延迟在合理范围。
• 效果：有效吞吐从68Gbps提升至92Gbps以上，大幅缩短了大规模模型训练的周期。

6. 建立你的性能基线：优化不是一次性的

所有优化做完，怎么证明有效？你需要建立一套属于自己硬件和业务场景的性能基线。这套基线应该是可重复执行的测试集，用于未来任何硬件、驱动、系统变更后的回归验证。

我建议至少包含以下三个测试：

把这些测试脚本化、定期跑、形成报告。优化不是一劳永逸的，系统更新、驱动升级、业务变化都可能带来性能回退。有了基线，你就能快速定位问题，判断优化方向是否正确。在海光平台这条国产化的性能探索之路上，这套全栈优化的方法论和可验证的实践体系，或许比你解决眼前这一个具体问题更为重要。毕竟，知其然并知其所以然，才能应对未来更多的挑战。