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

上传人:b****7 文档编号:26380584 上传时间:2023-06-18 格式:DOCX 页数:30 大小:702.47KB
下载 相关 举报
高性能服务器网络可伸缩性.docx_第1页
第1页 / 共30页
高性能服务器网络可伸缩性.docx_第2页
第2页 / 共30页
高性能服务器网络可伸缩性.docx_第3页
第3页 / 共30页
高性能服务器网络可伸缩性.docx_第4页
第4页 / 共30页
高性能服务器网络可伸缩性.docx_第5页
第5页 / 共30页
点击查看更多>>
下载资源
资源描述

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

《高性能服务器网络可伸缩性.docx》由会员分享,可在线阅读,更多相关《高性能服务器网络可伸缩性.docx(30页珍藏版)》请在冰豆网上搜索。

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

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

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

 

高性能可伸缩服务器的大量使用增加了网络和系统性能的复杂性。

在本文中,学习如何对多节点高性能Linux®系统进行优化(使用系统板载千兆以太网适配器,有1到4个节点)。

了解可能导致问题的网络可伸缩性场景以及避免问题的方法。

有许多资料讨论了网络性能、优化和调优,涉及各种硬件、平台和操作系统以及各种工作负载。

但是,高性能可伸缩服务器(比如IBM®eServer™xSeries®x460和IBMSystemx™3950)的大量使用毕竟增加了网络和系统性能的复杂性。

例如,对于可以通过添加完整的机架(或节点)来增加容量的可伸缩服务器,提高跨多节点系统的网络可伸缩性对总体系统性能非常重要。

系统配置

测试用系统(SUT)是一个4节点的IBMeServerxSeries460,运行SUSELinuxEnterpriseServer10forAMD64andEM64T(x86-64)。

每个节点的配置如下:

∙系统:

IBMeServerxSeries460

∙CPU:

4个64位Intel®Xeon®处理器70403.0GHz

∙内存:

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

∙以太网适配器:

Broadcom570410/100/1000dualEthernet/onsystemboard/64-bit266MHzPCI-X2.0

∙网络驱动程序:

tg3c3.49

∙网络类型:

千兆以太网

∙线程化:

超线程技术

所有测试场景都使用IBMSystemp5™550系统,每个系统有两个IntelDual-Port以太网适配器,运行RedHatEnterpriseLinux4Update4。

4节点的绑定(bond)测试还包含一个2节点的IBMeServerxSeries460,运行SUSELinuxEnterpriseServer10forAMD64andEM64T(x86-64)。

SUT和驱动程序通过一个CiscoCatalyst3750G-24TS交换机网络。

回页首

测试方法

由于多种原因,我选用netperf基准(具体地说,是单向流测试TCP_STREAM)测试可伸缩性演示工作负载,原因包括它的简单性、可度量性、在Linux上的稳定性、广泛的应用以及能够精确地度量批量数据传输性能。

它是一个基本的客户机-服务器模型基准,包含两个对应的可执行文件netperf和netserver。

简单的TCP_STREAM测试从netperf系统到netserver系统的数据传输时间,以此度量一个系统发送数据和另一个系统接收数据的速度。

在执行时,netperf建立一个到远程系统的控制连接(通过TCP)。

这个连接用来在系统之间传递配置信息和结果。

使用另一个连接执行度量,在此期间保留控制会话但是没有通信流(除非某些TCP选项需要通信)。

在这里描述的所有测试中,当IBMeServerxSeries460执行网络发送(netperf)、网络接收(netserver)或同时执行这两种操作(双向)时,都度量网络吞吐量和CPU利用率。

在客户机发送端记录客户机和服务器之间的吞吐量,并由netperf基准报告记录的数据。

每个环境的完整测试对于从64字节到256KB的15种消息大小分别执行3分钟的流测试。

这个范围包含1460和1480字节的消息大小,所以在Linux将消息分割为小数据包发送到网络之后,总的数据包大小接近默认的最大传输单位(MTU)1500。

在SUT上度量CPU利用率并由sysstat包中的sar实用程序报告,这一信息表示为netperf测试期间的系统平均值。

所有CPU和中断信息也来自sar数据。

在可伸缩性演示中,修改了配置和参数来影响行为。

以各种组合启用和禁用它们将导致不同的结果。

通过设置SMPIRQ亲合位掩码/proc/irq/nnn/smp_affinity,可以指定允许哪些CPU处理特定的中断。

Linux在初始化期间将它们设置为默认值。

可以启动守护进程irqbalance,在处理器之间动态地分发硬件中断。

如果启用这个守护进程,它会反复修改smp_affinity位掩码来执行分发。

可以使用numactl程序将特定的进程绑定到特定节点上的CPU和/或内存。

Linux网络绑定提供多种将多个网络接口合并为一个逻辑接口的方法,对于多节点服务器,这是一个有吸引力的网络管理特性。

回页首

性能和可伸缩性结果

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

1.开箱即用:

不修改软件配置

2.开箱即用加上numactl:

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

3.以太网SMPIRQ亲合:

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

4.以太网SMPIRQ亲合加上numactl:

这个测试环境组合了第二个和第三个配置

5.以太网绑定:

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

开箱即用配置

开箱即用测试在不修改软件配置的情况下运行。

在这个环境中,在Linux初始化期间默认启动irqbalance守护进程。

不修改SMPIRQ亲合,也不使用numactl和绑定。

第一个netserver可伸缩性测试在SUT的第一个节点的两个系统板载以太网适配器上各使用一个netserver实例。

每个netserver实例监听一个专用端口和IP地址;每个以太网适配器的IP地址属于单独的子网以确保专用的通信流。

远程驱动程序运行对应的netperf实例,从而按照远程netperf实例到SUTnetserver实例的一对一映射提供流通信。

完整测试使用15种不同的消息大小,对于每种消息大小执行3分钟的测试,并度量网络流吞吐量和系统CPU利用率。

第二个netserver可伸缩性测试使用前2个节点上的所有4个系统板载以太网适配器,第三个测试使用所有4个节点上的所有8个系统板载以太网适配器。

对于每个测试,相应地增加SUTnetserver实例和远程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节点

netserver

1.918

1.847

3.542

2.417

2.386

5.755

netperf

1.940

1.732

3.371

3.109

2.537

7.973

双向

1.888

1.892

3.569

2.368

2.274

5.413

因为这组测试中没有使用SMPIRQ亲合,所以所有以太网中断都在默认的/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

04.500.0070.180.000.0025.32

11.890.0088.540.000.009.57

21.680.0070.540.000.0027.77

30.660.004.810.000.0094.53

41.900.0080.430.000.0017.67

52.440.0082.380.000.0015.18

61.790.0070.550.000.0027.66

70.550.005.400.000.0094.04

83.910.0067.360.000.0028.73

91.660.0082.230.000.0016.11

100.210.004.370.000.0095.43

110.350.005.530.000.0094.12

120.130.001.970.000.0097.90

130.100.001.880.000.0098.03

140.090.002.140.090.0097.68

150.070.001.860.890.0097.18

.

.(未列出的值是0或接近0)

.

eth0eth1eth2eth3eth4eth5eth6eth7

CPUi177/si185/si193/si201/si209/si217/si225/si233/s

017542.700.000.000.000.000.000.000.00

10.000.000.000.000.0019515.860.000.00

20.000.000.0018612.580.000.000.000.00

30.000.000.000.000.000.000.000.00

40.000.000.000.0018816.800.000.000.00

50.000.0018545.740.000.000.000.000.00

60.000.000.000.000.000.0018609.160.00

70.000.000.000.000.000.000.000.00

80.0017506.100.000.000.000.000.000.00

90.000.000.000.000.000.000.0018606.14

.

.(未列出的值是0或接近0)

.

在这个环境中,尽管吞吐量变化并不很糟糕,但是随着越来越多的节点利用以太网适配器,CPU利用率的变化情况相当差。

CPU利用率快速增加的原因是,在非主节点上的以太网适配器中接收的中断却在主节点的CPU上处理,这导致了不必要的节点跳转。

在其他环境中收集的数据将表明,在这个环境中总吞吐量也会受损。

开箱即用配置加上numactl

这个环境中使用的可伸缩性测试和测试方法与开箱即用配置相同。

这两个环境之间的差异是,这个环境使用numactl将SUT上的netperf和/或netserver应用程序绑定到适当节点上的CPU和内存。

这些绑定确保应用程序在与它们使用的以太网适配器相同的节点的CPU上运行。

调用numactl的方法如下:

numactl--cpubind=node--preferred=nodenetserver

其中的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节点

netserver

1.900

1.763

3.362

3.860

2.639

10.332

netperf

1.923

1.807

3.466

3.555

2.056

7.268

双向

1.859

1.807

3.365

3.371

2.288

7.831

与前面的测试一样,因为这组测试中没有使用SMPIRQ亲合,所以所有以太网中断都在默认的/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

03.480.0079.710.000.0016.81

10.030.0073.550.000.0026.42

20.020.0067.800.000.0032.18

30.090.000.080.000.0099.83

40.000.0073.590.000.0026.41

50.030.0073.140.000.0026.83

60.010.0062.520.000.0037.47

70.040.000.070.000.0099.89

83.800.0071.700.000.0024.51

90.020.0068.800.000.0031.19

.

170.690.0092.920.000.006.39

180.010.000.000.000.0099.99

190.750.0092.900.000.006.36

.

320.770.0093.600.000.005.63

.

430.800.0093.570.000.005.63

.

490.760.0092.910.000.006.34

.

630.350.0093.310.000.006.35

 

eth0eth1eth2eth3eth4eth5eth6eth7

CPUi177/si185/si193/si201/si209/si217/si225/si233/s

016990.400.000.000.000.000.000.000.00

10.000.0011568.490.000.000.000.000.00

20.000.000.0013777.110.000.000.000.00

30.000.000.000.000.000.000.000.00

40.000.000.000.0010657.140.000.000.00

50.000.000.000.000.0010653.400.000.00

60.000.000.000.000.000.0013474.300.00

70.000.000.000.000.000.000.000.00

80.0016630.130.000.000.000.000.000.00

90.000.000.000.000.000.000.0012092.25

.

.(未列出的值是0或接近0)

.

不在以太网适配器所在的节点上处理网络中断肯定对性能不利。

在这种环境中,用numactl将网络应用程序绑定到以太网适配器所在的节点会使性能更糟糕。

在这个环境和前一个环境中收集的数据表明,吞吐量、CPU利用率和总可伸缩性都会受损。

以太网SMPIRQ亲合

这个环境中使用的可伸缩性测试和测试方法与开箱即用配置相同。

这两个环境之间的差异是,这个环境将每个以太网适配器的中断处理绑定到适配器所在的节点上的一个CPU。

另外,这个配置中不使用irqbalance。

将中断处理绑定到某个或某组CPU(亲合)的方法是,为给定的中断号设置smp_affinity位掩码。

这个位掩码表示应该处理给定中断的CPU。

在为中断启用亲合时,应该先停止irqbalance守护进程,否则它会反复修改smp_affinity值。

如果发生这种情况,亲合就会失效,以太网适配器的中断处理可能会在不合适的CPU上执行。

实际上,一个节点上的以太网适配器的中断处理可能在另一个节点的

展开阅读全文
相关资源
猜你喜欢
相关搜索

当前位置:首页 > 农林牧渔 > 林学

copyright@ 2008-2022 冰豆网网站版权所有

经营许可证编号:鄂ICP备2022015515号-1