Kunpeng 920处理器实战：如何优化64核性能提升服务器效率

Kunpeng 920处理器实战如何优化64核性能提升服务器效率最近几年数据中心和云计算领域对算力的需求呈现出爆炸式增长尤其是在人工智能、大数据分析和虚拟化等场景下。传统的服务器架构在处理高并发、高吞吐量任务时常常会遇到瓶颈。这时候像Kunpeng 920这样拥有64个核心的高性能处理器就成为了许多系统架构师和服务器管理员关注的焦点。但硬件只是基础如何让这64个核心真正“跑”起来让服务器的整体效率达到最优才是真正的挑战。这不仅仅是调整几个BIOS参数那么简单它涉及到从硬件架构理解、操作系统调度、到应用层优化的完整链条。如果你正在管理或规划基于Kunpeng 920的服务器集群或者对如何榨干多核处理器的性能潜力感到好奇那么接下来的内容或许能给你带来一些不一样的思路和可以直接上手的技巧。1. 深入理解Kunpeng 920的异构架构与资源分布要优化必须先理解。Kunpeng 920并非简单的64个同质化核心的堆叠其内部采用了多Die封装和Cluster核心簇的设计这直接影响了我们的优化策略。1.1 从Die与Cluster看NUMA效应Kunpeng 920将3个Die封装在一个芯片内其中两个是计算Die另一个是I/O Die。每个计算Die内部又包含了8个Cluster而每个Cluster由4个物理核心组成。因此总计是 2个Die * 8个Cluster/Die * 4个核心/Cluster 64个核心。这种层级结构带来了显著的非统一内存访问效应。一个核心访问其所在Die内的内存速度最快访问另一个计算Die上的内存延迟会稍高而访问需要通过I/O Die中转的设备内存或远端内存延迟则最高。操作系统如Linux会将这两个计算Die识别为两个独立的NUMA节点。提示在Linux系统中可以使用numactl -H命令来查看系统的NUMA拓扑结构包括节点数量、每个节点的内存大小以及节点间的距离代表访问延迟。了解NUMA拓扑后内存绑定的重要性就凸显出来了。如果让一个运行在NUMA节点0上的进程大量申请并使用NUMA节点1上的内存性能损耗会非常明显。对于数据库、高性能计算这类内存密集型应用必须进行NUMA绑定。# 示例使用numactl将进程绑定到特定的NUMA节点和CPU核心 # 将my_app绑定到NUMA节点0并且只使用该节点上的CPU0-31号逻辑核心 numactl --cpunodebind0 --membind0 ./my_app # 更精细的绑定将进程绑定到特定的物理核心例如绑定到0,2,4,6号物理核心 taskset -c 0,2,4,6 ./my_app1.2 缓存层次结构与数据局部性优化Kunpeng 920的缓存设计也紧密贴合其Cluster架构L1/L2缓存每个核心独享速度最快容量最小。L3缓存在一个计算Die内的所有核心即8个Cluster32个核心之间共享。这是容量最大的一级片上缓存。这种设计意味着紧密通信或共享数据的线程最好被调度到同一个Cluster甚至同一个Die内。这样它们可以通过共享的L3缓存进行高效通信避免频繁访问更慢的主内存。反之如果两个频繁交互的线程被分散在两个不同的NUMA节点上它们的数据同步将不得不通过内存总线性能会大打折扣。在实际的服务器配置中我们经常需要权衡。例如一个拥有128GB内存的服务器内存可能平均分配到两个NUMA节点上。对于单个需要64GB内存的大内存进程它可能不得不跨节点使用内存。此时我们可以通过调整内核的NUMA平衡策略来优化。# 查看当前的NUMA平衡策略 cat /proc/sys/kernel/numa_balancing # 对于性能极其敏感、且我们已进行手动绑定的应用可以临时关闭内核的NUMA自动平衡 echo 0 /proc/sys/kernel/numa_balancing2. 操作系统级核心调度与中断优化硬件资源就绪后操作系统的调度器就是决定性能的关键“指挥官”。对于64核系统默认的调度策略往往不是最优的。2.1 CPU调度策略与亲和性设置Linux内核的完全公平调度器CFS在通用场景下表现良好但对于追求极致低延迟或高吞吐量的应用可能需要调整。sched_setaffinity系统调用或taskset命令允许我们将进程或线程绑定到特定的CPU核心上这被称为CPU亲和性。绑定的好处在于减少缓存失效线程始终在固定的核心上运行其数据更可能保留在核心的本地缓存中。避免上下文切换开销线程不会被调度器迁移到其他核心消除了因迁移导致的缓存污染和TLB刷新开销。满足NUMA需求可以确保线程和其使用的内存位于同一NUMA节点。但是过度绑定也可能导致负载不均衡。一个常见的策略是为关键的后台服务或中间件如Redis、Nginx进行绑定而将通用的计算任务留给调度器。// 一个简单的示例在C程序中设置线程的CPU亲和性 #define _GNU_SOURCE #include sched.h #include pthread.h void pin_thread_to_cpu(pthread_t thread, int cpu_id) { cpu_set_t cpuset; CPU_ZERO(cpuset); CPU_SET(cpu_id, cpuset); // 绑定到cpu_id指定的核心 int rc pthread_setaffinity_np(thread, sizeof(cpu_set_t), cpuset); if (rc ! 0) { // 错误处理 } }2.2 中断请求IRQ的负载均衡与绑定服务器上的网络包、存储IO都会产生大量硬件中断。默认情况下这些中断可能由所有CPU核心处理这会导致频繁的缓存线在核心间移动影响性能。特别是对于Kunpeng 920集成的RoCE网卡和SAS控制器这类高性能IO设备中断处理路径的优化至关重要。我们可以将特定设备的中断请求绑定到少数几个专用的CPU核心上从而隔离中断对主要业务计算核心的影响。# 1. 找到网络接口例如eth0对应的中断号 grep eth0 /proc/interrupts | awk {print $1} | cut -d: -f1 # 假设找到的中断号是 123-130 # 2. 查看这些中断当前在哪些CPU上处理 cat /proc/irq/123/smp_affinity # 输出可能是 ffffffff表示所有CPU都可以处理 # 3. 将中断123绑定到CPU核心32即第二个NUMA节点的第一个核心 # 注意affinity值是十六进制位掩码。CPU0对应bit0CPU32对应bit32。 # 计算2^32 4294967296其十六进制为 100000000但系统通常显示简化的位掩码。 # 更简单的方法是直接使用位掩码文件 echo 1,32 /proc/irq/123/smp_affinity_list 2/dev/null || echo 100000001 /proc/irq/123/smp_affinity # 上述命令尝试使用cpu列表格式若不支持则使用位掩码格式将中断绑定到CPU0和CPU32通常不推荐绑两个这里仅为示例格式 # 更常见的做法将一组中断如123-130绑定到一组专用的核心如60-63 for irq in {123..130}; do echo 60-63 /proc/irq/$irq/smp_affinity_list 2/dev/null || echo f0000000 /proc/irq/$irq/smp_affinity done注意中断绑定需要谨慎操作。绑定的核心应避免运行关键业务线程。通常选择物理核心编号较高如最后几个核心或通过isolcpus内核参数隔离出来的核心作为中断处理专用核心。3. 内存与I/O子系统深度调优Kunpeng 920的I/O Die集成了高速网络和存储控制器这既是优势也带来了特定的优化点。3.1 利用集成RoCE实现高性能网络RoCERDMA over Converged Ethernet是Kunpeng 920的一大亮点。它允许应用程序远程直接访问其他服务器的内存完全绕过操作系统的内核网络协议栈和CPU。这对于分布式数据库如TiDB、高性能计算HPC、AI训练集群间的参数同步等场景能带来极致的低延迟和高吞吐。要启用RoCE不仅需要在硬件和驱动层面配置应用也需要使用支持RDMA的通信库如libibverbs和librdmacm。# 检查RDMA设备是否识别 ibv_devices # 输出应显示类似 mlx5_0 的设备如果使用Mellanox网卡或华为的RoCE设备 # 查看端口状态 ibv_devinfo在应用层面以使用OpenMPI进行高性能计算为例需要配置使用RDMA作为传输层# 启动MPI任务指定使用UCX通信框架并启用RDMA mpirun --hostfile my_hosts -np 64 \ -x UCX_TLSrc,sm \ -x UCX_NET_DEVICESmlx5_0:1 \ ./my_hpc_appUCX_TLSrc,sm指定使用RCReliable Connected传输和共享内存传输。UCX_NET_DEVICES指定使用的RDMA设备。3.2 SAS控制器与存储栈优化集成的SAS控制器为连接本地高速硬盘如SAS SSD提供了便利。优化存储性能的关键在于队列深度、I/O调度器和文件系统选择。队列深度对于NVMe或高速SAS SSD增加设备队列深度可以充分发挥其并行处理能力。可以通过sysfs调整。# 查看SAS设备例如/dev/sda的队列深度 cat /sys/block/sda/queue/nr_requests # 对于高性能SSD可以适当增加如增加到256 echo 256 /sys/block/sda/queue/nr_requestsI/O调度器对于高速固态硬盘noop或none多队列模式下为mq-deadline或kyber调度器通常是更好的选择因为它们减少了不必要的请求合并和排序开销让设备本身处理调度。# 查看当前调度器 cat /sys/block/sda/queue/scheduler # 设置为none (如果支持) 或 noop echo noop /sys/block/sda/queue/scheduler文件系统与挂载选项XFS或ext4是常见选择。挂载时使用noatime,nodiratime可以减少不必要的元数据更新barrier0在配备电池备份缓存BBU的RAID卡上可以禁用写入屏障以提升性能数据安全需保障。3.3 PCIe子系统与资源分配Kunpeng 920提供了丰富的PCIe通道用于扩展GPU、FPGA或其他加速卡。在虚拟化或容器化环境中需要合理分配这些资源。SR-IOV如果网卡或加速卡支持SR-IOV可以将其虚拟化成多个虚拟功能VF并直接分配给不同的虚拟机或容器实现接近物理性能的I/O。NUMA亲和性同样为PCIe设备分配资源时要考虑其连接的PCIe Root Port所属的NUMA节点。尽量让虚拟机或容器使用的CPU、内存和直通设备位于同一NUMA节点内。# 使用lspci查看PCIe设备及其所在的NUMA节点 lspci -vvv | grep -A 10 -B 5 -i numa # 或使用更专业的工具如 lstopo-no-graphics (来自hwloc包) lstopo-no-graphics --of txt | grep -i pci4. 实战场景构建高性能数据库服务器让我们以一个具体的场景——部署高性能MySQL数据库服务器——来串联上述优化技巧。4.1 环境准备与基准测试假设我们有一台双路Kunpeng 920服务器总计128核配备256GB内存每NUMA节点128GB使用集成的RoCE网卡和SAS SSD。首先进行未经优化的基准测试使用sysbench测试OLTP性能# 准备数据 sysbench oltp_read_write --table-size10000000 --tables10 --mysql-dbsbtest --mysql-userroot --mysql-passwordxxx prepare # 运行测试默认设置未绑定CPU/NUMA sysbench oltp_read_write --table-size10000000 --tables10 --mysql-dbsbtest --mysql-userroot --mysql-passwordxxx --threads128 --time300 --report-interval10 run记录下此时的TPS每秒事务数和延迟。4.2 分步实施优化第一步NUMA与CPU绑定修改MySQL启动脚本使用numactl将其绑定到第一个CPU插槽NUMA节点0。在MySQL配置文件my.cnf中设置innodb_buffer_pool_size为略小于节点0内存的值例如100GB确保缓冲池完全位于本地内存。将MySQL的服务线程如InnoDB的读写线程、日志线程通过innodb_read_io_threads和innodb_write_io_threads等参数进行配置并考虑使用taskset或numactl进行更细粒度的绑定。第二步中断绑定识别SAS控制器和RoCE网卡对应的中断号。将其中断绑定到预留的几个CPU核心上例如将最后4个核心124-127用于中断处理。可以通过在系统启动的GRUB参数中添加isolcpus124-127来隔离这些核心防止普通进程被调度上去。第三步存储优化将MySQL的数据目录和日志文件放在由SAS SSD组成的RAID卷上。将对应块设备的I/O调度器设置为noop。使用XFS文件系统并以noatime,nodiratime,barrier0选项挂载确保有BBU保护。调整MySQL的InnoDB日志文件大小innodb_log_file_size和刷新策略innodb_flush_log_at_trx_commit、innodb_flush_method以匹配高速存储的特性。第四步网络优化用于主从复制如果使用RoCE进行数据库主从复制间的日志传输需要特定MySQL分支或中间件支持配置使用RDMA通信能极大降低复制延迟。4.3 优化效果验证与监控再次运行sysbench测试对比优化前后的TPS和P99延迟。同时使用一系列监控工具来观察优化效果perf分析CPU缓存命中率、分支预测失败率等微观指标。perf stat -e cache-misses,cache-references,instructions,cycles ./mysql_processnumastat查看各NUMA节点的内存分配和跨节点访问情况目标是使numa_miss尽可能低。mpstat -P ALL观察每个CPU核心的利用率检查是否存在负载不均或个别核心如中断处理核心过忙的情况。iostat -x 1监控存储设备的利用率、队列长度和响应时间。经过这样一轮从硬件架构认知到操作系统、再到应用层的系统性调优我们通常能将Kunpeng 920服务器的潜力更充分地发挥出来。在我参与的一个金融风控计算项目中通过对类似架构的服务器进行上述优化将夜间批量处理作业的运行时间缩短了接近40%效果非常直接。当然每套业务系统都有其独特性最好的优化策略永远是基于实际负载的 profiling 和持续的迭代调整。