高性能服务器网络可伸缩性

豆豆网   技术应用频道   2008年01月22日  【字号: 收藏本文

内容摘要:高性能可伸缩服务器的大量使用增加了网络和系统性能的复杂性。在本文中,学习如何对多节点高性能 Linux® 系统进行优化(使用系统板载千兆以太网适配器,有 1 到 4 个节点)。了解可能导致问题的网络可伸缩性场景以及避免问题的方法。

  有许多资料讨论了网络性能、优化和调优,涉及各种硬件、平台和操作系统以及各种工作负载。但是,高性能可伸缩服务器(比如 IBM® eServer™ xSeries® x460 和 IBM System x™ 3950)的大量使用毕竟增加了网络和系统性能的复杂性。例如,对于可以通过添加完整的机架(或节点)来增加容量的可伸缩服务器,提高跨多节点系统的网络可伸缩性对总体系统性能非常重要。

  系统配置

  测试用系统(SUT)是一个 4 节点的 IBM eServer xSeries 460,运行 SUSE Linux Enterprise Server 10 for AMD64 and EM64T(x86-64)。每个节点的配置如下:

  系统: IBM eServer xSeries 460

  CPU: 4 个 64 位 Intel® Xeon® 处理器 7040 3.0GHz

  内存: 32GB(4 个内存卡上各有 8 个 1 GB DIMM)

  以太网适配器: Broadcom 5704 10/100/1000 dual Ethernet/on system board/64-bit 266MHz PCI-X 2.0

  网络驱动程序: tg3 c3.49

  网络类型: 千兆以太网

  线程化: 超线程技术

  所有测试场景都使用 IBM System p5™ 550 系统,每个系统有两个 Intel Dual-Port 以太网适配器,运行 Red Hat Enterprise Linux 4 Update 4。4 节点的绑定(bond)测试还包含一个 2 节点的 IBM eServer xSeries 460,运行 SUSE Linux Enterprise Server 10 for AMD64 and EM64T(x86-64)。SUT 和驱动程序通过一个 Cisco Catalyst 3750G-24TS 交换机网络。

  测试方法

  由于多种原因,我选用 netperf 基准(具体地说,是单向流测试 TCP_STREAM)测试可伸缩性演示工作负载,原因包括它的简单性、可度量性、在 Linux 上的稳定性、广泛的应用以及能够精确地度量批量数据传输性能。它是一个基本的客户机-服务器模型基准,包含两个对应的可执行文件 netperf 和 netserver。

  简单的 TCP_STREAM 测试从 netperf 系统到 netserver 系统的数据传输时间,以此度量一个系统发送数据和另一个系统接收数据的速度。在执行时,netperf 建立一个到远程系统的控制连接(通过 TCP)。这个连接用来在系统之间传递配置信息和结果。使用另一个连接执行度量,在此期间保留控制会话但是没有通信流(除非某些 TCP 选项需要通信)。

  在这里描述的所有测试中,当 IBM eServer xSeries 460 执行网络发送(netperf)、网络接收(netserver)或同时执行这两种操作(双向)时,都度量网络吞吐量和 CPU 利用率。在客户机发送端记录客户机和服务器之间的吞吐量,并由 netperf 基准报告记录的数据。

  每个环境的完整测试对于从 64 字节到 256KB 的 15 种消息大小分别执行 3 分钟的流测试。这个范围包含 1460 和 1480 字节的消息大小,所以在 Linux 将消息分割为小数据包发送到网络之后,总的数据包大小接近默认的最大传输单位(MTU)1500。在 SUT 上度量 CPU 利用率并由 sysstat 包中的 sar 实用程序报告,这一信息表示为 netperf 测试期间的系统平均值。所有 CPU 和中断信息也来自 sar 数据。

  在可伸缩性演示中,修改了配置和参数来影响行为。以各种组合启用和禁用它们将导致不同的结果。通过设置 SMP IRQ 亲合位掩码 /proc/irq/nnn/smp_affinity,可以指定允许哪些 CPU 处理特定的中断。Linux 在初始化期间将它们设置为默认值。可以启动守护进程 irqbalance,在处理器之间动态地分发硬件中断。如果启用这个守护进程,它会反复修改 smp_affinity 位掩码来执行分发。可以使用 numactl 程序将特定的进程绑定到特定节点上的 CPU 和/或内存。Linux 网络绑定提供多种将多个网络接口合并为一个逻辑接口的方法,对于多节点服务器,这是一个有吸引力的网络管理特性。

  性能和可伸缩性结果

  我们来看看以下配置的结果:

  开箱即用:不修改软件配置

  开箱即用加上 numactl:与前一个配置相同,但是使用 numactl 将 SUT 上的 netperf 和/或 netserver 应用程序绑定到适当节点上的 CPU 和内存

  以太网 SMP IRQ 亲合:与第一个配置相同,但是将每个以太网适配器的中断处理绑定到适配器所在的节点上的一个 CPU(不使用 irqbalance)

  以太网 SMP IRQ 亲合加上 numactl:这个测试环境组合了第二个和第三个配置

  以太网绑定:让一个大型多节点系统中的一些或所有以太网适配器共用一个 IP 地址

  开箱即用配置

  开箱即用测试在不修改软件配置的情况下运行。在这个环境中,在 Linux 初始化期间默认启动 irqbalance 守护进程。不修改 SMP IRQ 亲合,也不使用 numactl 和绑定。

  第一个 netserver 可伸缩性测试在 SUT 的第一个节点的两个系统板载以太网适配器上各使用一个 netserver 实例。每个 netserver 实例监听一个专用端口和 IP 地址;每个以太网适配器的 IP 地址属于单独的子网以确保专用的通信流。远程驱动程序运行对应的 netperf 实例,从而按照远程 netperf 实例到 SUT netserver 实例的一对一映射提供流通信。完整测试使用 15 种不同的消息大小,对于每种消息大小执行 3 分钟的测试,并度量网络流吞吐量和系统 CPU 利用率。

  第二个 netserver 可伸缩性测试使用前 2 个节点上的所有 4 个系统板载以太网适配器,第三个测试使用所有 4 个节点上的所有 8 个系统板载以太网适配器。对于每个测试,相应地增加 SUT netserver 实例和远程 netperf 实例的数量。

  图 1 显示 netserver 可伸缩性测试的网络流吞吐量和系统 CPU 利用率,分别使用 SUT 中 1、2 和 4 个节点上的系统板载以太网适配器。

  图 1. 采用开箱即用配置的 SUT 上的 netserver

高性能服务器网络可伸缩性

  放大图 1。

  这里显示的吞吐量是每个测试使用的所有以太网适配器的吞吐量总和;CPU 利用率是测试期间的系统平均值。

  接下来,按照与 netserver 可伸缩性测试相同的方式执行 netperf 可伸缩性测试,惟一的差异是 netperf 在 SUT 上运行,netserver 在远程系统上运行。

  图 2 显示 netperf 可伸缩性测试的网络流吞吐量和系统 CPU 利用率,分别使用 SUT 中 1、2 和 4 个节点上的系统板载以太网适配器。

  图 2. 采用开箱即用配置的 SUT 上的 netperf

高性能服务器网络可伸缩性

  放大图 2。

  这里显示的吞吐量是每个测试使用的所有以太网适配器的吞吐量总和;CPU 利用率是测试期间的系统平均值。

  最后,按照与前面的 netserver 和 netperf 测试相似的方式执行双向可伸缩性测试。但是,在这种测试中,只使用任何节点的第一个系统板载以太网适配器,而且只使用一个 netserver 实例和一个 netperf 实例。再次重申,每个以太网适配器有两个基准实例(一个 netserver 和一个 netperf),每个节点只使用一个以太网适配器。对应的 netperf 或 netserver 远程实例在它自己的以太网适配器上运行,以确保尽可能完整地测试与 SUT 之间的通信流。

  图 3 显示双向可伸缩性测试的网络流吞吐量和系统 CPU 利用率,分别使用 SUT 中 1、2 和 4 个节点上的系统板载以太网适配器。

  图 3. 采用开箱即用配置的 SUT 上的 netperf 和 netserver(双向)

高性能服务器网络可伸缩性

  放大图 3。

  这里显示的吞吐量是每个测试使用的所有以太网适配器的吞吐量总和;CPU 利用率是测试期间的系统平均值。

  对于每种消息大小,分别计算从 2 个适配器/1 个节点到 4 个适配器/2 个节点的吞吐量变化。对于 netserver 可伸缩性测试,这些值的范围从 1.647(比较小的消息大小)到 1.944(比较大的消息大小)。所有值的平均值是 1.918。同样,对于每种消息大小,分别计算从 2 个适配器/1 个节点到 4 个适配器/2 个节点的 CPU 利用率变化。对于 netserver 可伸缩性测试,这些值的范围从 2.770 到 1.623。在这个环境中,所有值的平均值是 2.417。

  对于每种消息大小,还分别计算从 4 个适配器/2 个节点到 8 个适配器/4 个节点的吞吐量和 CPU 利用率变化。吞吐量变化范围从 1.666 到 1.900,平均值是 1.847。CPU 利用率变化范围从 2.599 到 1.884,平均值是 2.386。

  对于所有消息大小,从 2 个适配器/1 个节点到 8 个适配器/4 个节点的平均吞吐量变化是 3.542。对于所有消息大小,从 2 个适配器/1 个节点到 8 个适配器/4 个节点的平均 CPU 利用率变化是 5.755。

  表 1 给出 netserver、netperf 和双向测试的平均变化计算值。

  表 1. netserver、netperf 和双向测试的变化计算值

测试平均吞吐量变化,1 到 2 节点平均吞吐量变化,2 到 4 节点平均吞吐量变化,1 到 4 节点平均 CPU 利用率变化,1 到 2 节点平均 CPU 利用率变化,2 到 4 节点平均 CPU 利用率变化,1 到 4 节点
netserver1.9181.8473.5422.4172.3865.755
netperf1.9401.7323.3713.1092.5377.973
双向1.8881.8923.5692.3682.2745.413

  因为这组测试中没有使用 SMP IRQ 亲合,所以所有以太网中断都在默认的 /proc/irq/nnn/smp_affinity 值所指定的 CPU 上处理(在初始化时 irqbalance 会修改这些值)。显示每个系统 CPU 的 CPU 利用率和中断数等信息的 sar 数据表明,无论以太网适配器是否在任何其他节点上,所有网络中断都在第一个节点的 CPU 上处理。这导致了不必要的节点跳转延迟。

  清单 1 给出 netserver 可伸缩性测试的部分 sar 数据(在所有 4 个节点上的所有以太网适配器上运行 netserver)。这组数据针对 8KB 的消息大小,可以代表这个环境中的所有测试。所有值都是 3 分钟的测试期间的平均值。

  清单 1. 开箱即用配置的 sar 数据

CPU   %user   %nice  %system  %iowait  %steal  %idle
0   4.50   0.00   70.18   0.00   0.00   25.32
1   1.89   0.00   88.54   0.00   0.00   9.57
2   1.68   0.00   70.54   0.00   0.00   27.77
3   0.66   0.00   4.81   0.00   0.00   94.53
4   1.90   0.00   80.43   0.00   0.00   17.67
5   2.44   0.00   82.38   0.00   0.00   15.18
6   1.79   0.00   70.55   0.00   0.00   27.66
7   0.55   0.00   5.40   0.00   0.00   94.04
8   3.91   0.00   67.36   0.00   0.00   28.73
9   1.66   0.00   82.23   0.00   0.00   16.11
10   0.21   0.00   4.37   0.00   0.00   95.43
11   0.35   0.00   5.53   0.00   0.00   94.12
12   0.13   0.00   1.97   0.00   0.00   97.90
13   0.10   0.00   1.88   0.00   0.00   98.03
14   0.09   0.00   2.14   0.09   0.00   97.68
15   0.07   0.00   1.86   0.89   0.00   97.18
.
.   (未列出的值是 0 或接近 0)
.
    eth0   eth1   eth2   eth3   eth4   eth5   eth6   eth7
CPU   i177/s  i185/s  i193/s  i201/s  i209/s  i217/s  i225/s  i233/s
0  17542.70   0.00   0.00   0.00   0.00   0.00   0.00   0.00
1    0.00   0.00   0.00   0.00   0.00 19515.86   0.00   0.00
2    0.00   0.00   0.00 18612.58   0.00   0.00   0.00   0.00
3    0.00   0.00   0.00   0.00   0.00   0.00   0.00   0.00
4    0.00   0.00   0.00   0.00 18816.80   0.00   0.00   0.00
5    0.00   0.00 18545.74   0.00   0.00   0.00   0.00   0.00
6    0.00   0.00   0.00   0.00   0.00   0.00 18609.16   0.00
7    0.00   0.00   0.00   0.00   0.00   0.00   0.00   0.00
8    0.00 17506.10   0.00   0.00   0.00   0.00   0.00   0.00
9    0.00   0.00   0.00   0.00   0.00   0.00   0.00 18606.14
.
.  (未列出的值是 0 或接近 0)
.

  在这个环境中,尽管吞吐量变化并不很糟糕,但是随着越来越多的节点利用以太网适配器,CPU 利用率的变化情况相当差。CPU 利用率快速增加的原因是,在非主节点上的以太网适配器中接收的中断却在主节点的 CPU 上处理,这导致了不必要的节点跳转。在其他环境中收集的数据将表明,在这个环境中总吞吐量也会受损。

  开箱即用配置加上 numactl

  这个环境中使用的可伸缩性测试和测试方法与开箱即用配置相同。这两个环境之间的差异是,这个环境使用 numactl 将 SUT 上的 netperf 和/或 netserver 应用程序绑定到适当节点上的 CPU 和内存。这些绑定确保应用程序在与它们使用的以太网适配器相同的节点的 CPU 上运行。调用 numactl 的方法如下:

  numactl --cpubind=node --preferred=node netserver

  其中的 cpubind=node 指定应该使用哪个节点的 CPU 执行这个进程,preferred=node 指定应该为这个进程分配哪个节点上的内存。如果在这个节点上无法分配内存,就在另一个节点的内存中分配。

  按照与开箱即用配置相同的方式,执行 netserver 可伸缩性测试并收集数据。

  图 4 显示 netserver 可伸缩性测试的网络流吞吐量和系统 CPU 利用率,分别使用 SUT 中 1、2 和 4 个节点上的系统板载以太网适配器。

  图 4. netserver,开箱即用配置加上 numactl

高性能服务器网络可伸缩性

  放大图 4。

  这里显示的吞吐量是每个测试使用的所有以太网适配器的吞吐量总和;CPU 利用率是测试期间的系统平均值。

  按照与前一个环境相同的方式执行 netperf 可伸缩性测试。图 5 显示 netperf 可伸缩性测试的网络流吞吐量和系统 CPU 利用率,分别使用 SUT 中 1、2 和 4 个节点上的系统板载以太网适配器。

  图 5. netperf,开箱即用配置加上 numactl

高性能服务器网络可伸缩性

  放大图 5。

  这里显示的吞吐量是每个测试使用的所有以太网适配器的吞吐量总和;CPU 利用率是测试期间的系统平均值。

  按照与前一个环境相同的方式执行双向可伸缩性测试。图 6 显示双向可伸缩性测试的网络流吞吐量和系统 CPU 利用率,分别使用 SUT 中 1、2 和 4 个节点上的系统板载以太网适配器。

  图 6. netperf 和 netserver(双向),开箱即用配置加上 numactl

高性能服务器网络可伸缩性

  放大图 6。

  这里显示的吞吐量是每个测试使用的所有以太网适配器的吞吐量总和;CPU 利用率是测试期间的系统平均值。

  与开箱即用测试一样,在从 1 个节点扩展到 2 个节点、2 个节点到 4 个节点和 1 个节点到 4 个节点的情况下,分别计算 netserver、netperf 和双向测试的平均变化值。结果见表 2。

  表 2. netserver、netperf 和双向测试(开箱即用配置加上 numactl)的变化计算值

测试平均吞吐量变化,1 到 2 节点平均吞吐量变化,2 到 4 节点平均吞吐量变化,1 到 4 节点平均 CPU 利用率变化,1 到 2 节点平均 CPU 利用率变化,2 到 4 节点平均 CPU 利用率变化,1 到 4 节点
netserver1.9001.7633.3623.8602.63910.332
netperf1.9231.8073.4663.5552.0567.268
双向1.8591.8073.3653.3712.2887.831

  与前面的测试一样,因为这组测试中没有使用 SMP IRQ 亲合,所以所有以太网中断都在默认的 /proc/irq/nnn/smp_affinity 值所指定的 CPU 上处理(在初始化时 irqbalance 会修改这些值)。sar 数据表明,无论以太网适配器是否在任何其他节点上,所有中断都在第一个节点的 CPU 上处理;即使用 numactl 将应用程序绑定到所用以太网适配器的节点上的 CPU 和内存,情况也是如此。实际上,当在另一个节点上处理适配器的中断时,将 netperf 或 netserver 绑定到所用以太网适配器的节点上的 CPU 会显著增加 CPU 总利用率。

  清单 2 给出 netserver 可伸缩性测试的部分 sar 数据(在所有 4 个节点上的所有以太网适配器上运行 netserver)。这组数据针对 8KB 的消息大小,可以代表这个环境中的所有测试。所有值都是 3 分钟的测试期间的平均值。

  清单 2. 开箱即用配置加上 numactl 的 sar 数据

CPU   %user   %nice  %system  %iowait  %steal  %idle
0   3.48   0.00   79.71   0.00   0.00   16.81
1   0.03   0.00   73.55   0.00   0.00   26.42
2   0.02   0.00   67.80   0.00   0.00   32.18
3   0.09   0.00   0.08   0.00   0.00   99.83
4   0.00   0.00   73.59   0.00   0.00   26.41
5   0.03   0.00   73.14   0.00   0.00   26.83
6   0.01   0.00   62.52   0.00   0.00   37.47
7   0.04   0.00   0.07   0.00   0.00   99.89
8   3.80   0.00   71.70   0.00   0.00   24.51
9   0.02   0.00   68.80   0.00   0.00   31.19
.
17   0.69   0.00   92.92   0.00   0.00   6.39
18   0.01   0.00   0.00   0.00   0.00   99.99
19   0.75   0.00   92.90   0.00   0.00   6.36
.
32   0.77   0.00   93.60   0.00   0.00   5.63
.
43   0.80   0.00   93.57   0.00   0.00   5.63
.
49   0.76   0.00   92.91   0.00   0.00   6.34
.
63   0.35   0.00   93.31   0.00   0.00   6.35
    eth0   eth1   eth2   eth3   eth4   eth5   eth6   eth7
CPU   i177/s  i185/s  i193/s  i201/s  i209/s  i217/s  i225/s  i233/s
0  16990.40   0.00   0.00   0.00   0.00   0.00   0.00   0.00
1    0.00   0.00 11568.49   0.00   0.00   0.00   0.00   0.00
2    0.00   0.00   0.00 13777.11   0.00   0.00   0.00   0.00
3    0.00   0.00   0.00   0.00   0.00   0.00   0.00   0.00
4    0.00   0.00   0.00   0.00 10657.14   0.00   0.00   0.00
5    0.00   0.00   0.00   0.00   0.00 10653.40   0.00   0.00
6    0.00   0.00   0.00   0.00   0.00   0.00 13474.30   0.00
7    0.00   0.00   0.00   0.00   0.00   0.00   0.00   0.00
8    0.00 16630.13   0.00   0.00   0.00   0.00   0.00   0.00
9    0.00   0.00   0.00   0.00   0.00   0.00   0.00 12092.25
.
.  (未列出的值是 0 或接近 0)
.

  不在以太网适配器所在的节点上处理网络中断肯定对性能不利。在这种环境中,用 numactl 将网络应用程序绑定到以太网适配器所在的节点会使性能更糟糕。在这个环境和前一个环境中收集的数据表明,吞吐量、CPU 利用率和总可伸缩性都会受损。

  以太网 SMP IRQ 亲合

  这个环境中使用的可伸缩性测试和测试方法与开箱即用配置相同。这两个环境之间的差异是,这个环境将每个以太网适配器的中断处理绑定到适配器所在的节点上的一个 CPU。另外,这个配置中不使用 irqbalance。

  将中断处理绑定到某个或某组 CPU(亲合)的方法是,为给定的中断号设置 smp_affinity 位掩码。这个位掩码表示应该处理给定中断的 CPU。在为中断启用亲合时,应该先停止 irqbalance 守护进程,否则它会反复修改 smp_affinity 值。如果发生这种情况,亲合就会失效,以太网适配器的中断处理可能会在不合适的 CPU 上执行。实际上,一个节点上的以太网适配器的中断处理可能在另一个节点的 CPU 上执行。用以下命令停止 irqbalance:

  killproc -TERM /usr/sbin/irqbalance

  还要在引导初始化脚本中删除相应的命令。

  为了将一个中断绑定到某个或某组 CPU,首先要决定应该让哪些 CPU 处理这个中断,然后相应地编写位掩码。掩码中最右边的一位对应于 CPU0,下一位对应于 CPU1,以此类推。可以设置多位来表示一组 CPU。然后,执行以下命令来设置位掩码值:

  echo bitmask > /proc/irq/IRQ_number/smp_affinity

  例如,以下命令将 IRQ 号为 177 的中断的处理绑定到 CPU4 到 CPU7(位掩码 11110000):

  echo f0 > /proc/irq/177/smp_affinity

  注意,在将 smp_affinity 设置为包含多个 CPU 的位掩码时,实验中观察到的现象是:网络中断总是在位掩码指定的第一个 CPU 上处理。如果两个中断的位掩码中设置的第一位相同,那么这两个中断都在这一位指定的 CPU 上处理。例如,如果两个以太网适配器中断的 smp_affinity 位掩码都是 0000ffff,那么它们都在 CPU0 上处理。因此,目前最好不要让不同的以太网适配器中断的 smp_affinity 位掩码设置相同的位,除非确实希望在相同的 CPU 上处理它们。

  这个测试设置的 smp_affinity 位掩码如下:

第一个节点上的第一个以太网适配器:  00000000,000000f0
第一个节点上的第二个以太网适配器:  00000000,0000f000
第二个节点上的第一个以太网适配器:  00000000,00f00000
第二个节点上的第二个以太网适配器:  00000000,f0000000
第三个节点上的第一个以太网适配器:  000000f0,00000000
第三个节点上的第二个以太网适配器:  0000f000,00000000
第四个节点上的第一个以太网适配器:  00f00000,00000000
第四个节点上的第二个以太网适配器:  f0000000,00000000

  这些设置确保每个以太网适配器的中断都在这个适配器所在的节点的 CPU 上处理。有意地不让 CPU 0 处理网络中断,因为这个 CPU 通常用来处理许多工作负载。

  按照与开箱即用配置相同的方式,执行 netserver、netperf 和双向可伸缩性测试并收集数据。图 7 显示 netserver 可伸缩性测试的网络流吞吐量和系统 CPU 利用率,分别使用 SUT 中 1、2 和 4 个节点上的系统板载以太网适配器。

  图 7. netserver,以太网 SMP IRQ 亲合,不使用 irqbalance

高性能服务器网络可伸缩性

  放大图 7。

  这里显示的吞吐量是每个测试使用的所有以太网适配器的吞吐量总和;CPU 利用率是测试期间的系统平均值。

  按照与前一个环境相同的方式执行 netperf 可伸缩性测试。图 8 显示 netperf 可伸缩性测试的网络流吞吐量和系统 CPU 利用率,分别使用 SUT 中 1、2 和 4 个节点上的系统板载以太网适配器。

  图 8. netperf,以太网 SMP IRQ 亲合,不使用 irqbalance

高性能服务器网络可伸缩性

  放大图 8。

  这里显示的吞吐量是每个测试使用的所有以太网适配器的吞吐量总和;CPU 利用率是测试期间的系统平均值。

  图 9 显示双向可伸缩性测试的网络流吞吐量和系统 CPU 利用率,分别使用 SUT 中 1、2 和 4 个节点上的系统板载以太网适配器。这里显示的吞吐量是每个测试使用的所有以太网适配器的吞吐量总和;CPU 利用率是测试期间的系统平均值。

  图 9. netperf 和 netserver(双向),以太网 SMP IRQ 亲合,不使用 irqbalance

高性能服务器网络可伸缩性

  放大图 9。

  与开箱即用测试一样,在从 1 个节点扩展到 2 个节点、2 个节点到 4 个节点和 1 个节点到 4 个节点的情况下,分别计算 netserver、netperf 和双向测试的平均变化值。结果见表 3。

  表 3. netserver、netperf 和双向测试(以太网 SMP IRQ 亲合,不使用 irqbalance)的变化计算值

测试平均吞吐量变化,1 到 2 节点平均吞吐量变化,2 到 4 节点平均吞吐量变化,1 到 4 节点平均 CPU 利用率变化,1 到 2 节点平均 CPU 利用率变化,2 到 4 节点平均 CPU 利用率变化,1 到 4 节点
netserver1.9901.9413.8612.0112.0354.095
netperf2.0021.7703.5422.0421.9614.005
双向1.9711.9683.8742.2411.9904.456

  清单 3 给出 netserver 可伸缩性测试的部分 sar 数据(在所有 4 个节点上的所有以太网适配器上运行 netserver)。这组数据针对 8KB 的消息大小,可以代表这个环境中的所有测试。所有值都是 3 分钟的测试期间的平均值。数据表明,所有中断都在通过 SMP IRQ 亲合绑定的 CPU 上处理。

  清单 3. 以太网 SMP IRQ 亲合配置(不使用 irqbalance)的 sar 数据

CPU   %user   %nice  %system  %iowait  %steal  %idle
0   0.05   0.00   0.05   0.00   0.00   99.90
.
4   2.22   0.00   49.21   0.00   0.00   48.57
.
12   2.21   0.00   49.27   0.02   0.00   48.51
.
20   2.25   0.00   51.59   0.00   0.00   46.17
.
28   2.23   0.00   51.47   0.00   0.00   46.29
.
36   2.86   0.00   56.06   0.00   0.00   41.08
.
44   2.29   0.00   51.87   0.00   0.00   45.84
.
52   2.69   0.00   55.28   0.00   0.00   42.02
.
60   2.66   0.00   55.35   0.00   0.00   41.98
.
.   (未列出的值是 0 或接近 0)
.
    eth0   eth1   eth2   eth3   eth4   eth5   eth6   eth7
CPU   i177/s  i185/s  i193/s  i201/s  i209/s  i217/s  i225/s  i233/s
4 15969.26   0.00   0.00   0.00   0.00   0.00   0.00   0.00
.
12   0.00 15959.40   0.00   0.00   0.00   0.00   0.00   0.00
.
20   0.00   0.00 15721.47   0.00   0.00   0.00   0.00   0.00
.
28   0.00   0.00   0.00 15693.93   0.00   0.00   0.00   0.00
.
36   0.00   0.00   0.00   0.00 16000.84   0.00   0.00   0.00
.
44   0.00   0.00   0.00   0.00   0.00 15981.13   0.00   0.00
.
52   0.00   0.00   0.00   0.00   0.00   0.00 15855.95   0.00
.
60   0.00   0.00   0.00   0.00   0.00   0.00   0.00 15700.12
.
.  (未列出的值是 0 或接近 0)
.

  在以太网适配器所在的节点的 CPU 上处理它们的中断(并禁用 irqbalance)会大大降低 CPU 利用率和增加吞吐量,可以同时改进吞吐量和 CPU 利用率可伸缩性。

  以太网 SMP IRQ 亲合加上 numactl

  这个环境中使用的可伸缩性测试和测试方法与开箱即用配置相同。这个测试环境组合了前面二个测试环境的特性。用与前一组测试相同的位掩码启用 SMP IRQ 亲合,禁用 irqbalance,并使用 numactl 将 SUT 上的 netperf 和/或 netserver 绑定到适当节点上的 CPU 和内存。这些 numactl 绑定确保这些应用程序的实例在与它们使用的以太网适配器相同的节点的 CPU 上运行,并使用这些节点上的内存。

  按照与开箱即用配置相同的方式,执行 netserver、netperf 和双向可伸缩性测试并收集数据。图 10 显示 netserver 可伸缩性测试的网络流吞吐量和系统 CPU 利用率,分别使用 SUT 中 1、2 和 4 个节点上的系统板载以太网适配器。

  图 10. netserver,以太网 SMP IRQ 亲合和 numactl,不使用 irqbalance

高性能服务器网络可伸缩性

  放大图 10。

  这里显示的吞吐量是每个测试使用的所有以太网适配器的吞吐量总和;CPU 利用率是测试期间的系统平均值。

  按照与前一个环境相同的方式执行 netperf 可伸缩性测试。图 11 显示 netperf 可伸缩性测试的网络流吞吐量和系统 CPU 利用率,分别使用 SUT 中 1、2 和 4 个节点上的系统板载以太网适配器。这里显示的吞吐量是每个测试使用的所有以太网适配器的吞吐量总和;CPU 利用率是测试期间的系统平均值。

  图 11. netperf,以太网 SMP IRQ 亲合和 numactl,不使用 irqbalance

高性能服务器网络可伸缩性

  放大图 11。

  接下来重复双向可伸缩性测试。图 12 显示测试的网络流吞吐量和系统 CPU 利用率,分别使用 SUT 中 1、2 和 4 个节点上的系统板载以太网适配器。这里显示的吞吐量是每个测试使用的所有以太网适配器的吞吐量总和;CPU 利用率是测试期间的系统平均值。

  图 12. 双向,以太网 SMP IRQ 亲合和 numactl,不使用 irqbalance

高性能服务器网络可伸缩性

  放大图 12。

  变化计算值见表 4。

  表 4. 变化计算值(以太网 SMP IRQ 亲合和 numactl,不使用 irqbalance)

测试平均吞吐量变化,1 到 2 节点平均吞吐量变化,2 到 4 节点平均吞吐量变化,1 到 4 节点平均 CPU 利用率变化,1 到 2 节点平均 CPU 利用率变化,2 到 4 节点平均 CPU 利用率变化,1 到 4 节点
netserver1.9991.9453.8882.0762.0814.324
netperf2.0021.7623.5272.0382.0644.206
双向1.9931.9353.8582.0161.9603.953

  清单 4 给出 netserver 可伸缩性测试的部分 sar 数据(在所有 4 个节点上的所有以太网适配器上运行 netserver)。这组数据针对 8KB 的消息大小,可以代表这个环境中的所有测试。所有值都是 3 分钟的测试期间的平均值。数据表明,所有中断都在通过亲合绑定的 CPU 上处理。

  清单 4. 以太网 SMP IRQ 亲合配置加上 numactl(不使用 irqbalance)的 sar 数据

CPU   %user   %nice  %system  %iowait  %steal   %idle
4   2.25   0.00   49.29   0.03   0.00   48.43
.
12   2.61   0.00   51.82   0.00   0.00   45.58
.
20   2.25   0.00   51.84   0.00   0.00   45.91
.
28   2.85   0.00   57.43   0.00   0.00   39.72
.
36   2.06   0.00   50.21   0.00   0.00   47.72
.
44   2.04   0.00   53.34   0.00   0.00   44.62
.
52   2.03   0.00   52.34   0.00   0.00   45.62
.
60   2.28   0.00   54.28   0.00   0.00   43.44
.
.   (未列出的值是 0 或接近 0)
.
    eth0   eth1   eth2   eth3   eth4   eth5   eth6   eth7
CPU   i177/s  i185/s  i193/s  i201/s  i209/s  i217/s  i225/s  i233/s
4  15962.89   0.00   0.00   0.00   0.00   0.00   0.00   0.00
.
12    0.00 15660.56   0.00   0.00   0.00   0.00   0.00   0.00
.
20    0.00   0.00 15690.78   0.00   0.00   0.00   0.00   0.00
.
28    0.00   0.00   0.00 15696.00   0.00   0.00   0.00   0.00
.
36    0.00   0.00   0.00   0.00 15726.10   0.00   0.00   0.00
.
44    0.00   0.00   0.00   0.00   0.00 15574.72   0.00   0.00
.
52    0.00   0.00   0.00   0.00   0.00   0.00 15682.12   0.00
.
60    0.00   0.00   0.00   0.00   0.00   0.00   0.00 15700.46
.
.  (未列出的值是 0 或接近 0)
.

  与前一组测试一样,在以太网适配器所在的节点的 CPU 上处理它们的中断(并禁用 irqbalance)会大大降低 CPU 利用率并改进吞吐量可伸缩性。在此基础上,使用 numactl 将网络应用程序绑定到与使用的以太网适配器相同的节点的 CPU 和内存上,会略微改进吞吐量、CPU 利用率和可伸缩性。

  以太网绑定

  可以让一个大型多节点系统中的一些或所有以太网适配器共用一个 IP 地址,这对系统管理和网络管理有帮助。正如前面提到的,绑定(bonding)是 Linux 中的一个特性,它提供多种将多个网络接口合并为一个逻辑接口的方法。

  大多数 Linux 发行版都包含绑定驱动程序和支持实用程序 ifenslave。可以配置这个驱动程序,可以用 6 种绑定策略在绑定式接口之间平衡通信流。这些策略包括:

  balance-rr(循环)

  adaptive-backup

  balance-xor

  broadcast

  802.3ad

  balance-tlb(传输负载平衡)

  balance-alb(适应性负载平衡)

  本文主要关注 balance-alb 策略(有时称为 “mode 6”),因为它容易设置,不需要额外的硬件或开关配置,它会在绑定式接口之间平衡发送和接收负载。

  在 SUT 上设置绑定的方法如下:

  用适应性负载平衡模式(mode 6)和 up-delay 参数(链路恢复之后到启用从进程之前等待的毫秒数)装载绑定模块:modprobe bonding mode=6 updelay=200。

  配置并启动 bond 接口:ifconfig bond0 ip_address netmask netmask broadcast bcast 。

  将参与绑定的所有接口连接到 bond 接口:ifenslave bond0 eth0 eth1 eth2 eth3。

  为了演示绑定对性能和可伸缩性的影响,禁用 irqbalance 并像前一个测试环境一样设置以太网 SMP IRQ 亲合,然后执行 netserver 可伸缩性测试。使用的以太网适配器被绑定到一个接口,共用一个 IP 地址;驱动程序中的每个远程 netperf 实例都向这个绑定式接口的 IP 地址发送消息。

  按照与开箱即用配置相同的方式,执行 netserver 可伸缩性测试并收集数据,但是每个节点上只使用一个以太网适配器。图 13 显示 netserver 可伸缩性测试的网络流吞吐量和系统 CPU 利用率,分别使用 SUT 中 1、2 和 4 个节点上绑定的第一个系统板载以太网适配器。

  图 13. netserver,以太网 SMP IRQ 亲合,不使用 irqbalance,绑定式接口

高性能服务器网络可伸缩性

  放大图 13。

  这里显示的吞吐量是每个测试使用的所有以太网适配器的吞吐量总和;CPU 利用率是测试期间的系统平均值。

  与开箱即用测试类似,变化计算值见表 5。

  表 5. 变化计算值(以太网 SMP IRQ 亲合,不使用 irqbalance,绑定式接口)

测试平均吞吐量变化,1 到 2 节点平均吞吐量变化,2 到 4 节点平均吞吐量变化,1 到 4 节点平均 CPU 利用率变化,1 到 2 节点平均 CPU 利用率变化,2 到 4 节点平均 CPU 利用率变化,1 到 4 节点
netserver1.8791.9263.6242.7712.3356.486

  清单 5 给出 netserver 可伸缩性测试的部分 sar 数据(在绑定式接口上运行 netserver),这些数据是所有 4 个节点上的第一个系统板载以太网适配器的数据汇总。这组数据针对 8KB 的消息大小,可以代表这个环境中的所有测试。所有值都是 3 分钟的测试期间的平均值。数据表明,所有中断都在它们绑定的 CPU 上处理。

  清单 5. 以太网 SMP IRQ 亲合配置(不使用 irqbalance,使用绑定式接口)的 sar 数据

CPU   %user   %nice  %system  %iowait  %steal  %idle
4   2.02   0.00   72.32   0.00   0.00   25.67
.
20   2.37   0.00   77.83   0.00   0.00   19.80
.
36   1.72   0.00   74.71   0.00   0.00   23.57
.
52   1.62   0.00   78.48   0.00   0.00   19.89
.
.   (未列出的值是 0 或接近 0)
.
    eth0   eth1   eth2   eth3   eth4   eth5   eth6   eth7
CPU   i177/s  i185/s  i193/s  i201/s  i209/s  i217/s  i225/s  i233/s
4  16353.36   0.00   0.00   0.00   0.00   0.00   0.00   0.00
.
20    0.00   0.00 15693.97   0.00   0.00   0.00   0.00   0.00
.
36    0.00   0.00   0.00   0.00 15386.92   0.00   0.00   0.00
.
52    0.00   0.00   0.00   0.00   0.00   0.00 15570.74   0.00
.
.  (未列出的值是 0 或接近 0)
.

  图 14 对比了在启用和禁用绑定的情况下 netserver 可伸缩性测试的结果,测试使用 2 个适配器(前 2 个节点上各使用一个适配器)和 4 个适配器(所有 4 个节点上各使用一个适配器)。这里显示的吞吐量是每个测试使用的所有以太网适配器的吞吐量总和;CPU 利用率是测试期间的系统平均值。

  图 14. 启用和禁用绑定的 netserver 测试对比,以太网 SMP IRQ 亲合,不使用 irqbalance

高性能服务器网络可伸缩性

  放大图 14。

  测试结果表明,尽管以太网绑定增加了一些开销,但是与没有启用绑定的情况相比,以太网接口的网络可伸缩性和性能都有所改进。启用绑定给管理带来的好处和对网络应用程序的简化会超过它的性能开销。

  结束语

  当使用高性能可伸缩服务器节点上的多个网络适配器时,默认的 Linux 开箱即用配置可能没有提供最好的性能和可伸缩性。在本文描述的环境中,在默认情况下,无论适配器实际上在哪个节点上,以太网适配器的中断处理都在第一个节点的 CPU 上进行。这种行为会损害网络吞吐量、CPU 利用率以及总体网络性能和可伸缩性。不适当的配置会不必要地增加 CPU 利用率,从而损害总体系统性能。

  为了获得最好的性能和可伸缩性,应该确保在以太网适配器的本地节点的 CPU 上处理中断。可以将中断处理绑定到适当的 CPU(亲合),方法是首先停止 irqbalance,从初始化脚本中删除它,启用 SMP IRQ 亲合并在引导初始化脚本中设置亲合配置。如果不先停止 irqbalance,亲合就会失效。成功地配置了 SMP IRQ 亲合之后,应该尽可能将网络应用程序绑定到所用以太网适配器的本地节点上的处理器。

  以太网绑定是一个有用的 Linux 特性,它提供多种将多个网络接口合并为一个逻辑接口的方法。它能够以比较低的开销简化网络管理。

  测试结果表明,如果在 IBM eServer xSeries x460 系统上正确地跨节点使用以太网适配器,Linux 的网络可伸缩性非常好。对于多种消息大小,当从 1 个节点上的 2 个以太网适配器扩展到 2 个节点上的 4 个适配器时,平均吞吐量变化最高可达 1.99;当从 2 个节点上的 4 个以太网适配器扩展到 4 个节点上的 8 个适配器时,平均吞吐量变化最高可达 1.945。对应的平均 CPU 利用率变化为 2.076 和 2.081。

来源:ibm    作者:Barry Arndt    责编:豆豆技术应用

正在加载评论...