能源效率在数据中心和高性能系统中的重要性日益凸显。能源成本可能占据运营支出预算的相当大部分，甚至成为企业成败的关键因素。本文深入探讨现代服务器平台的能效问题，介绍了测量功耗和性能的工具与方法论。作为案例研究，我们展示了两种不同CPU架构服务器平台的测量结果，重点分析网络性能（包括吞吐量测量）、CPU利用率和功耗，特别关注实现每瓦特能耗的最高吞吐量。

测试方法

评估计算机性能与功耗需求的关系可分为三个关键步骤：

• 评估计算机性能
• 测量计算机功耗需求
• 将性能相对于功耗进行标准化

我们以每个物理CPU核心可实现的吞吐量（千兆位/秒）来衡量系统性能。需要注意的是，对于现代高速（100 Gbps及以上）以太网适配器，单个用户空间进程几乎不可能利用所有可用带宽。此外，网络吞吐量只是性能的一部分。理想情况下，处理网络流量应消耗最少的资源，让系统大部分资源可用于创建或处理通过网络传输的数据。理想情况下，应使用尽可能少的内核使CPU饱和。

为量化这些需求，我们监控以下指标：

• 最大可实现吞吐量（千兆位/秒）
• 总CPU利用率（以核心数衡量）。为简化起见，两个半负载核心计为一个全负载核心
• 计算效率，计算为吞吐量（Gbps）与CPU利用率的比率。例如，使用两个CPU核心处理60 Gbps吞吐量的系统，其计算效率为每核心30 Gbps

测量网络吞吐量

我们使用开源的iperf3基准测试工具测量网络吞吐量，该工具被广泛认为是行业标准。用于基准测试的确切命令：

1

iperf3 --json --client 172.16.0.42 --time 30 --port 5201 --parallel 8

--parallel 8选项指定使用8个同时的TCP套接字发送流量，但仅使用单个用户空间进程。这种方法有助于减轻接收方缩放（RSS）哈希函数的伪影，并确保结果可重现。替代方法涉及固定远程和本地TCP端口，并使用ethtool ntuple功能配置RSS以在CPU之间均匀分配流。我们选择并行套接字方法，因为并非我们测试中使用的每个网络接口控制器（NIC）最初都支持ntuple RSS配置。这种方法的一个潜在缺点是当数据在多个CPU核心上处理时缓存行为不理想。但由于所有测试使用相同的配置，结果仍然具有可比性。

测量CPU利用率

我们使用mpstat命令测量CPU利用率：

1

mpstat -P ALL 30

我们在启动iperf3基准测试之前以编程方式启动mpstat进程。此示例中的数字30表示CPU使用情况将被监控30秒，与iperf3运行的持续时间匹配。

即使在本地和远程端的吞吐量保持不变，CPU利用率也不同。接收数据通常比发送数据更消耗CPU，因为发送方使用TCP分段卸载（TSO）将数据分片卸载到NIC，而接收方必须在软件中重新组装数据。因此，应在发送端和接收端都监控CPU利用率。在大多数情况下，我们报告远程CPU利用率，因为这是决定可实现吞吐量的更重要因素。

计算效率

为评估计算效率，我们将吞吐量除以总系统负载，并乘以100的因子。除以100是必要的，因为mpstat将CPU利用率报告为百分比，而我们希望以完全加载的核心数表示：

1

计算效率 = 吞吐量(Gbps) / (CPU利用率/100)

此方程提供了单个完全加载核心的假设性能。

网络密集型进程操作模式

被测系统在不同操作条件下可能表现不同。我们在以下操作模型中测试系统：

单进程

仅运行一个用户空间进程。通常使用两个CPU核心：一个用于iperf3进程，另一个用于处理中断。此处，CPU时钟频率和每周期指令数决定了实现的吞吐量，理想情况下应尽可能高。

多进程

运行多个用户空间进程，但仍未完全饱和可用带宽。CPU多核性能成为实现吞吐量的分母。理想情况下，吞吐量应线性扩展。核心数加倍应大致使吞吐量加倍。

饱和

在此模型中，运行足够的用户空间进程以饱和链路，意味着吞吐量达到NIC的线路速率或最大潜在吞吐量。添加更多进程不会增加吞吐量或整体系统负载。相反，额外的进程应调度到同一组CPU核心上。

为测量多核和饱和性能，我们同时运行多个并行iperf3实例。iperf3和mpstat进程的编排由Nepta处理，这是红帽开发的基准测试工具。

处理单个网络流涉及操作系统处理的两个主要任务：

• 运行生成或接收网络流量的网络密集型用户空间进程
• 处理网卡生成的大量中断

优化工作负载的硬件局部性

在此阶段，了解硬件至关重要。几乎所有服务器硬件都使用非统一内存访问（NUMA）架构，这意味着访问时间因访问的内存区域而异。

每个CPU核心都有本地内存（附加到物理上最接近核心的内存控制器，通常在同一硅片或插槽上）和远程内存（附加到不同插槽或芯片上的内存控制器）。

类似地，连接到同一硅片上控制器的PCI设备被视为本地PCI设备，而所有其他设备被视为远程PCI设备。

CPU核心、PCI设备、内存控制器和相邻内存模块的组合形成NUMA节点。

可以使用lstopo实用程序可视化硬件拓扑。您可以查看其文本输出：

1

lstopo

您可以通过定义输出图形文件生成图像：

1

lstopo topology.png

下面是表示硬件拓扑的生成PNG文件示例：

网络密集型进程的NUMA感知资源分配

从网络密集型进程的角度来看，网卡可以位于本地NUMA节点或远程NUMA节点上。在远程节点上运行进程通常会导致两位数性能损失。然而，这并不意味着远程核心应保持空闲——即使有性能损失，使用它通常比完全闲置更好。

目前，Linux调度器考虑内存局部性，但不优化进程的I/O需求。优化这方面完全是用户的责任。

基于经验，以下资源分配策略被推荐：

1. 网络密集型进程少于带网卡的NUMA节点上的CPU核心数：

   • 将本地NUMA节点上的一些CPU核心专用于网络密集型进程
   • 将同一节点上的其他CPU核心专用于处理中断

2. 网络密集型进程多于NUMA节点上的CPU核心数，但不超过系统中总CPU核心数的两倍：

   • 将本地NUMA节点上的所有CPU核心专用于服务中断
   • 将系统中所有剩余CPU核心专用于网络密集型进程

3. 数千个网络密集型进程或需要跨多个NUMA节点资源的进程：

   • 使用默认的红帽企业Linux（RHEL）配置。RHEL默认针对此场景进行了优化

固定中断和进程

可以使用tuna实用程序将特定网络驱动程序生成的中断固定到CPU子集：

1

sudo tuna --spread=0-12 --irqs=$(grep ice /proc/interrupts | awk '{print $1}' | sed 's/://')

此命令将ice驱动程序生成的所有网络中断分布在CPU 0-12上。

可以使用taskset将网络相关进程固定到特定CPU核心。对于新启动的进程：

1

taskset -c 1 ./process

对于已运行的进程，使用pgrep或pidof或ps获取进程的PID，并将其传递给taskset：

1

taskset -cp 1 <PID>

当运行多个网络相关进程时，每个进程应固定到其自己的专用CPU。许多网络守护进程还提供配置选项，将子进程固定到特定CPU，这可以进一步优化性能。

测试中的硬件环境

本文档的目标不是比较不同计算平台的性能或功耗。红帽的目标不是对系统进行相互基准测试，而是在所有可用硬件上提供最佳性能。

对于此案例研究，我们使用三个具有不同CPU架构、核心数和系统内存大小的服务器系统。这些系统仅用于说明计算和功率效率的分析。对于基准测试，我们专注于网络密集型进程数小于最近NUMA节点上CPU核心数的简单场景。

系统1：入门级ARM服务器

• CPU：32核心 @ 1.7 GHz
• 基准测试配置：最多16个iperf3实例，16个核心专用于处理中断，16个核心专用于运行iperf进程

系统2：高性能ARM服务器

• CPU：80核心 @ 2.2 GHz
• 基准测试配置：最多40个iperf3实例，40个核心专用于处理中断，40个核心专用于运行iperf进程

系统3：传统x64服务器

• CPU：32核心 @ 3.2 GHz
• 基准测试配置：最多40个iperf3实例，40个核心专用于处理中断，40个核心专用于运行iperf进程

每个系统的CPU固定配置总结在下表中：

评估计算机系统功耗

测量计算机系统功耗有三种常见方法：

外部功率计

使用校准的外部功率计（瓦特计）是测量总系统功率的最可靠方法。然而，它提供对单个组件（如CPU、SSD或内存）功耗的有限洞察。一些高级功率计包括用于自动读取的串行接口，但通过串行线自动化通常繁琐复杂。

系统实用程序

某些CPU供应商提供用于深入功率分析的命令行工具。这些工具提供对CPU行为的详细洞察，包括缓存、内存控制器和PCI控制器的功耗。然而，它们仅测量CPU功率，无法监控系统的其余部分，如电源或存储设备。

平台管理

一些平台供应商将功率测量集成到平台管理接口中。这种方法结合了外部仪表和CPU实用程序的优点：可靠、可自动化，并提供组件级洞察。不幸的是，这种能力并非在所有系统上都普遍可用。

幸运的是，我们所有的测试系统都配备了机箱级功率监控，可通过ipmitool访问：

1

sudo ipmitool sdr

此命令返回所有硬件传感器的读数，包括风扇速度、电压和（最重要的）功耗值。在我们的系统上，以下功率指标可用：

• PSU1 Power In：电源1的AC输入功率
• PSU1 Power Out：电源1的DC输出功率
• PSU2 Power In：电源2的AC输入功率
• PSU2 Power Out：电源2的DC输出功率
• CPU_Power：CPU消耗的DC功率，在主板电压调节器处测量
• Memory_Power（仅x64系统）：在主板电压调节器处测量的DRAM功率

我们针对AC瓦特计（AC侧）和DC钳形表（DC侧）验证了这些读数。来自ipmitool的所有读数都在外部测量的5%以内，使我们对它们的准确性充满信心。

需要注意的是，ipmitool报告瞬时读数。在初始测试中，我们观察到功率在基准测试的第一秒后稳定，并保持稳定直到完成。因此，为简化起见，我们在每个基准测试运行15秒时获取单个读数。

将性能相对于功耗标准化

为将实验合并为单一指标，我们将最大实现吞吐量除以功耗。指标在PSU的DC侧和CPU本身都计算。

我们测试的最终性能指标是：

• CPU能效：兆位/秒/瓦（CPU消耗的每瓦特吞吐量）
• 系统能效：兆位/秒/瓦（整个系统消耗的每瓦特吞吐量，不包括PSU损耗）

关于电源的说明

开关模式电源效率的详细讨论超出了本文档的范围。然而，强调一些关键点很重要。

现代服务器电源通常在额定容量的20%到90%的广泛负载范围内实现高效率。超出此范围，效率可能迅速下降。大多数通过80 Plus Platinum认证的现代PSU必须在大于其额定容量20%的负载下实现90%以上的效率。虽然令人印象深刻，但在使用低功耗、高效CPU时，这可能不太相关。

我们的系统配备了两个冗余的800W电源，总容量为1600W。为达到其额定效率，这些PSU需要至少320W（组合容量的20%）的最小负载。现代服务器CPU的TDP通常为100W或更少。在我们的测试中，即使在全负载下，也没有系统达到320W阈值。

缓解策略

为改善低功率条件下的效率，我们实施了以下措施：

使用较低额定功率的电源

我们用400W单元替换了原来的800W PSU，减少了合理效率所需的最小负载。

启用热备用模式

我们配置平台管理，使所有负载从第一个PSU汲取，而第二个PSU保持热备用以实现冗余。例如，从单个400W PSU汲取72W的32核ARM系统以额定容量的18%运行，略低于20%阈值，但仍实现了82%的效率。

直接测量DC输出

为避免PSU效率的非线性，本文中的所有功率效率指标基于DC输出测量而非AC输入。

考虑PSU效率的好处

通过评估系统功率输入并相应调整PSU，可以：

• 通过避免过度配置、昂贵的电源来降低CAPEX
• 通过提高整体效率、降低系统功耗和运营成本来减少OPEX

结论

在本研究中，我们评估了计算机系统性能与功耗之间的关系，重点关注网络密集型工作负载。我们的方法总结：

评估系统性能

• 性能测量为每个CPU核心可实现的网络吞吐量
• 我们考虑了CPU利用率、最大吞吐量和计算效率（每个完全加载核心的吞吐量）
• 测试了不同操作模式——单进程、多进程和饱和——以捕获真实性能行为

优化工作负载的硬件局部性

• 我们强调NUMA感知，将网络密集型进程和中断处理与本地内存和PCI设备对齐
• 利用CPU固定和中断分布减少远程内存访问的性能损失

测量功耗

• 使用平台管理接口通过ipmitool监控功率，使用外部AC/DC仪表验证
• 记录CPU功率和系统范围功率，并使用DC侧测量考虑PSU效率

将性能相对于功耗标准化

• 最终指标结合吞吐量和功耗，产生CPU和系统级能效（Mbit/s/W）
• 考虑了PSU效率，制定了优化低负载操作和减少浪费的策略

本文的目标是为客户提供测量网络性能和优化功耗的实用方法论，帮助他们在设计、调整或扩展网络密集型系统时做出明智决策。

总体而言，这种方法突出了硬件感知调度、准确功率测量和节能系统设计的重要性，为现代数据中心环境提供了可操作的见解。