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

1、高性能服务器网络可伸缩性高性能服务器网络可伸缩性高性能可伸缩服务器的大量使用增加了网络和系统性能的复杂性。在本文中，学习如何对多节点高性能 Linux 系统进行优化（使用系统板载千兆以太网适配器，有 1 到 4 个节点）。了解可能导致问题的网络可伸缩性场景以及避免问题的方法。有许多资料讨论 了网络性能、优化和调优，涉及各种硬件、平台和操作系统以及各种工作负载。但是，高性能可伸缩服务器（比如 IBM eServer xSeries x460 和 IBM System x 3950）的大量使用毕竟增加了网络和系统性能的复杂性。例如，对于可以通过添加完整的机架（或节点）来增加容量的可伸缩服务器，提高

2、跨多节点系统的网络 可伸缩性对总体系统性能非常重要。 系统配置测试用系统（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/

3、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

4、和驱动程序通过一个 Cisco Catalyst 3750G-24TS 交换机网络。 回页首测试方法由于多种原因，我选用 netperf 基准（具体地说，是单向流测试 TCP_STREAM）测试可伸缩性演示工作负载，原因包括它的简单性、可度量性、在 Linux 上的稳定性、广泛的应用以及能够精确地度量批量数据传输性能。它是一个基本的客户机-服务器模型基准，包含两个对应的可执行文件 netperf 和 netserver。简单的 TCP_STREAM 测试从 netperf 系统到 netserver 系统的数据传输时间，以此度量一个系统发送数据和另一个系统接收数据的速度。在执行时，netper

5、f 建立一个到远程系统的控制连接（通过 TCP）。这个连接用来在系统之间传递配置信息和结果。使用另一个连接执行度量，在此期间保留控制会话但是没有通信流（除非某些 TCP 选项需要通信）。 在这里描述的所有测试中，当 IBM eServer xSeries 460 执行网络发送（netperf）、网络接收（netserver）或同时执行这两种操作（双向）时，都度量网络吞吐量和 CPU 利用率。在客户机发送端记录客户机和服务器之间的吞吐量，并由 netperf 基准报告记录的数据。 每 个环境的完整测试对于从 64 字节到 256KB 的 15 种消息大小分别执行 3 分钟的流测试。这个范围包含

6、1460 和 1480 字节的消息大小，所以在 Linux 将消息分割为小数据包发送到网络之后，总的数据包大小接近默认的最大传输单位（MTU）1500。在 SUT 上度量 CPU 利用率并由 sysstat 包中的 sar 实用程序报告，这一信息表示为 netperf 测试期间的系统平均值。所有 CPU 和中断信息也来自 sar 数据。 在可伸缩性演示中，修改了配置和参数来影响行为。以各种组合启用和 禁用它们将导致不同的结果。通过设置 SMP IRQ 亲合位掩码 /proc/irq/nnn/smp_affinity，可以指定允许哪些 CPU 处理特定的中断。Linux 在初始化期间将它们设置为

7、默认值。可以启动守护进程 irqbalance，在处理器之间动态地分发硬件中断。如果启用这个守护进程，它会反复修改 smp_affinity 位掩码来执行分发。可以使用 numactl 程序将特定的进程绑定到特定节点上的 CPU 和/或内存。Linux 网络绑定提供多种将多个网络接口合并为一个逻辑接口的方法，对于多节点服务器，这是一个有吸引力的网络管理特性。 回页首性能和可伸缩性结果我们来看看以下配置的结果： 1. 开箱即用：不修改软件配置2. 开箱即用加上 numactl：与前一个配置相同，但是使用 numactl 将 SUT 上的 netperf 和/或 netserver 应用程序绑定到

8、适当节点上的 CPU 和内存3. 以太网 SMP IRQ 亲合：与第一个配置相同，但是将每个以太网适配器的中断处理绑定到适配器所在的节点上的一个 CPU（不使用 irqbalance）4. 以太网 SMP IRQ 亲合加上 numactl：这个测试环境组合了第二个和第三个配置5. 以太网绑定：让一个大型多节点系统中的一些或所有以太网适配器共用一个 IP 地址开箱即用配置开箱即用测试在不修改软件配置的情况下运行。在这个环境中，在 Linux 初始化期间默认启动 irqbalance 守护进程。不修改 SMP IRQ 亲合，也不使用 numactl 和绑定。 第 一个 netserver 可伸缩性

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

10、 个节点上的所有 8 个系统板载以太网适配器。对于每个测试，相应地增加 SUT netserver 实例和远程 netperf 实例的数量。 图 1 显示 netserver 可伸缩性测试的网络流吞吐量和系统 CPU 利用率，分别使用 SUT 中 1、2 和 4 个节点上的系统板载以太网适配器。 图 1. 采用开箱即用配置的 SUT 上的 netserver放大图 1。 这里显示的吞吐量是每个测试使用的所有以太网适配器的吞吐量总和；CPU 利用率是测试期间的系统平均值。 接下来，按照与 netserver 可伸缩性测试相同的方式执行 netperf 可伸缩性测试，惟一的差异是 netperf

11、在 SUT 上运行，netserver 在远程系统上运行。 图 2 显示 netperf 可伸缩性测试的网络流吞吐量和系统 CPU 利用率，分别使用 SUT 中 1、2 和 4 个节点上的系统板载以太网适配器。 图 2. 采用开箱即用配置的 SUT 上的 netperf放大图 2。 这里显示的吞吐量是每个测试使用的所有以太网适配器的吞吐量总和；CPU 利用率是测试期间的系统平均值。 最 后，按照与前面的 netserver 和 netperf 测试相似的方式执行双向可伸缩性测试。但是，在这种测试中，只使用任何节点的第一个系统板载以太网适配器，而且只使用一个 netserver 实例和一个 ne

12、tperf 实例。再次重申，每个以太网适配器有两个基准实例（一个 netserver 和一个 netperf），每个节点只使用一个以太网适配器。对应的 netperf 或 netserver 远程实例在它自己的以太网适配器上运行，以确保尽可能完整地测试与 SUT 之间的通信流。 图 3 显示双向可伸缩性测试的网络流吞吐量和系统 CPU 利用率，分别使用 SUT 中 1、2 和 4 个节点上的系统板载以太网适配器。 图 3. 采用开箱即用配置的 SUT 上的 netperf 和 netserver（双向）放大图 3。 这里显示的吞吐量是每个测试使用的所有以太网适配器的吞吐量总和；CPU 利用率是

13、测试期间的系统平均值。 对 于每种消息大小，分别计算从 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 个节

14、点的吞吐量和 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 节点平均吞吐量变

15、化，2 到 4 节点平均吞吐量变化，1 到 4 节点平均 CPU 利用率变化，1 到 2 节点平均 CPU 利用率变化，2 到 4 节点平均 CPU 利用率变化，1 到 4 节点netserver1.9181.8473.5422.4172.3865.755netperf1.9401.7323.3713.1092.5377.973双向1.8881.8923.5692.3682.2745.413因为这组测试中没有使用 SMP IRQ 亲合，所以所有以太网中断都在默认的 /proc/irq/nnn/smp_affinity 值所指定的 CPU 上处理（在初始化时 irqbalance 会修改这些值）

16、。显示每个系统 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.

17、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

18、82.23 0.00 0.00 16.1110 0.21 0.00 4.37 0.00 0.00 95.4311 0.35 0.00 5.53 0.00 0.00 94.1212 0.13 0.00 1.97 0.00 0.00 97.9013 0.10 0.00 1.88 0.00 0.00 98.0314 0.09 0.00 2.14 0.09 0.00 97.6815 0.07 0.00 1.86 0.89 0.00 97.18 . . （未列出的值是 0 或接近 0） . eth0 eth1 eth2 eth3 eth4 eth5 eth6 eth7CPU i177/s i185/s

19、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

20、.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 利用率快速增加的原因是，在非主节点上的以太网适

21、配器中接收的中断却在主节点的 CPU 上处理，这导致了不必要的节点跳转。在其他环境中收集的数据将表明，在这个环境中总吞吐量也会受损。 开箱即用配置加上 numactl这个环境中使用的可伸缩性测试和测试方法与开箱即用配置相同。这两个环境之间的差异是，这个环境使用 numactl 将 SUT 上的 netperf 和/或 netserver 应用程序绑定到适当节点上的 CPU 和内存。这些绑定确保应用程序在与它们使用的以太网适配器相同的节点的 CPU 上运行。调用 numactl 的方法如下： numactl -cpubind=node -preferred=node netserver 其中的

22、cpubind=node 指定应该使用哪个节点的 CPU 执行这个进程，preferred=node 指定应该为这个进程分配哪个节点上的内存。如果在这个节点上无法分配内存，就在另一个节点的内存中分配。 按照与开箱即用配置相同的方式，执行 netserver 可伸缩性测试并收集数据。 图 4 显示 netserver 可伸缩性测试的网络流吞吐量和系统 CPU 利用率，分别使用 SUT 中 1、2 和 4 个节点上的系统板载以太网适配器。 图 4. netserver，开箱即用配置加上 numactl放大图 4。 这里显示的吞吐量是每个测试使用的所有以太网适配器的吞吐量总和；CPU 利用率是测试期

23、间的系统平均值。 按照与前一个环境相同的方式执行 netperf 可伸缩性测试。图 5 显示 netperf 可伸缩性测试的网络流吞吐量和系统 CPU 利用率，分别使用 SUT 中 1、2 和 4 个节点上的系统板载以太网适配器。 图 5. netperf，开箱即用配置加上 numactl放大图 5。 这里显示的吞吐量是每个测试使用的所有以太网适配器的吞吐量总和；CPU 利用率是测试期间的系统平均值。 按照与前一个环境相同的方式执行双向可伸缩性测试。图 6 显示双向可伸缩性测试的网络流吞吐量和系统 CPU 利用率，分别使用 SUT 中 1、2 和 4 个节点上的系统板载以太网适配器。 图 6.

24、 netperf 和 netserver（双向），开箱即用配置加上 numactl放大图 6。 这里显示的吞吐量是每个测试使用的所有以太网适配器的吞吐量总和；CPU 利用率是测试期间的系统平均值。 与开箱即用测试一样，在从 1 个节点扩展到 2 个节点、2 个节点到 4 个节点和 1 个节点到 4 个节点的情况下，分别计算 netserver、netperf 和双向测试的平均变化值。结果见表 2。 表 2. netserver、netperf 和双向测试（开箱即用配置加上 numactl）的变化计算值测试平均吞吐量变化，1 到 2 节点平均吞吐量变化，2 到 4 节点平均吞吐量变化，1 到 4

25、 节点平均 CPU 利用率变化，1 到 2 节点平均 CPU 利用率变化，2 到 4 节点平均 CPU 利用率变化，1 到 4 节点netserver1.9001.7633.3623.8602.63910.332netperf1.9231.8073.4663.5552.0567.268双向1.8591.8073.3653.3712.2887.831与前面的测试一样，因为这组测试中没有使用 SMP IRQ 亲合，所以所有以太网中断都在默认的 /proc/irq/nnn/smp_affinity 值所指定的 CPU 上处理（在初始化时 irqbalance 会修改这些值）。sar 数据表明，无论以

26、太网适配器是否在任何其他节点上，所有中断都在第一个节点的 CPU 上处理；即使用 numactl 将应用程序绑定到所用以太网适配器的节点上的 CPU 和内存，情况也是如此。实际上，当在另一个节点上处理适配器的中断时，将 netperf 或 netserver 绑定到所用以太网适配器的节点上的 CPU 会显著增加 CPU 总利用率。 清单 2 给出 netserver 可伸缩性测试的部分 sar 数据（在所有 4 个节点上的所有以太网适配器上运行 netserver）。这组数据针对 8KB 的消息大小，可以代表这个环境中的所有测试。所有值都是 3 分钟的测试期间的平均值。 清单 2. 开箱即用配

27、置加上 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.

28、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.3918 0.01 0.00 0.00 0.00 0.00 99.9919 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

29、0.00 6.34 .63 0.35 0.00 93.31 0.00 0.00 6.35 eth0 eth1 eth2 eth3 eth4 eth5 eth6 eth7CPU i177/s i185/s i193/s i201/s i209/s i217/s i225/s i233/s0 16990.40 0.00 0.00 0.00 0.00 0.00 0.00 0.001 0.00 0.00 11568.49 0.00 0.00 0.00 0.00 0.002 0.00 0.00 0.00 13777.11 0.00 0.00 0.00 0.003 0.00 0.00 0.00 0.00

30、0.00 0.00 0.00 0.004 0.00 0.00 0.00 0.00 10657.14 0.00 0.00 0.005 0.00 0.00 0.00 0.00 0.00 10653.40 0.00 0.006 0.00 0.00 0.00 0.00 0.00 0.00 13474.30 0.007 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.008 0.00 16630.13 0.00 0.00 0.00 0.00 0.00 0.009 0.00 0.00 0.00 0.00 0.00 0.00 0.00 12092.25. （未列出的值是 0 或接近

31、 0）.不在以太网适配器所在的节点上处理网络中断肯定对性能不利。在这种环境中，用 numactl 将网络应用程序绑定到以太网适配器所在的节点会使性能更糟糕。在这个环境和前一个环境中收集的数据表明，吞吐量、CPU 利用率和总可伸缩性都会受损。 以太网 SMP IRQ 亲合这个环境中使用的可伸缩性测试和测试方法与开箱即用配置相同。这两个环境之间的差异是，这个环境将每个以太网适配器的中断处理绑定到适配器所在的节点上的一个 CPU。另外，这个配置中不使用 irqbalance。 将中断处理绑定到某个或某组 CPU（亲合）的方法是，为给定的中断号设置 smp_affinity 位掩码。这个位掩码表示应该处理给定中断的 CPU。在为中断启用亲合时，应该先停止 irqbalance 守护进程，否则它会反复修改 smp_affinity 值。如果发生这种情况，亲合就会失效，以太网适配器的中断处理可能会在不合适的 CPU 上执行。实际上，一个节点上的以太网适配器的中断处理可能在另一个节点的