性能指标之资源指标-网络IO-关注指标

有时系统性能的低下是由于网络带宽不足、网络抖动或者服务器端的相关参数配置导致的。本节介绍网络IO的相关指标。

一、 配置

1.1 最大带宽

LPAR能够占用的最大带宽是有网络管理员/运营商配置决定的。如果需要了解某个LPAR的最大带宽或者某N个LPAR共同占用的最大带宽，需咨询网络管理员。

需要提醒一点，网络是有损耗的，比如控制包等因素，实际的带宽占用达不到100%，例如ATM网络达到85~90%就基本达到网络带宽瓶颈了。

1.2 操作系统配置

事实上，网络相关的参数配置很少会被关注，一般均采用操作系统及中间件的默认配置。因为网络相关参数很少会明显影响到系统的性能表现，也就是说，很少会被用户感知到。本章仅做简单介绍。

1. 获取来源
NMON BBBP SHEET
命令行no –F –L

2. 详细解释
参数之多无法直视。可以参考man no，或者最新版本（比如AIX Version 7.2）的《Networks and communication management》，
http://public.dhe.ibm.com/systems/power/docs/aix/72/commadmndita_pdf.pdf

这里简单介绍几个常见的、可能会被修改的参数
1）Socket的发送/接收缓冲区的尺寸（sb_max、tcp_recvspace、tcp_sendspace、udp_recvspace、udp_sendspace）
2）启用 TCP 优化，设定 RFC 1323（TCP 扩展到高性能）。rfc1323值为 1 表示 tcp_sendspace and tcp_recvspace 可以超过 64 KB。
3）tcp_nodelayack禁用延迟的应答

通常情况下，在服务器之间收发数据包，依据 TCP 协议，节点 A 向节点 B 发送一个数据报文 , 节点 B 收到这个数据报文以后，会向节点 A 返回一个 acknowledge 信息。延迟 ACK 机制：TCP 在接收到数据时不立即向发送方返回ACK，而是延迟发送。一般延迟时间是 200ms。在等待发送ACK 期间，TCP收集需要往另一端发送的数据，直到收集的数据大小超过 MSS 的定义或者延迟时间超时，TCP才将ACK信息和需要发送的数据合并成一个报文一起发送。这样有利于减少网络中的数据包，避免网络拥塞

针对tcp_nodelayack的实验

在一个“报文从起点出发 -> 报文传输 -> 服务器A处理转发 -> 报文传输 -> 服务器B处理转发 -> 报文传输 -> 报文回到起点”的验证系统中，针对4KB小报文和1.2 MB大报文分别进行测试，观察tcp_nodelayack=1的效果。

在处理4KB小报文时，当设置tcp_nodelayack=1 禁用延迟的应答后，报文流转全流程时间减少13.8毫秒或16.3%，网络带宽占用增加26.4 KB/s或1.4%。

在处理1.2MB大报文时，当设置tcp_nodelayack=1 禁用延迟的应答后，报文流转全流程时间减少41.2毫秒或1.9%，网络带宽占用增加221.6 KB/s或2.1%。

禁用延迟的应答对小报文的传输效率提升较为明显，对大报文传输效率提升不明显（百分比较小）。如果排除掉服务器的处理转发时间（这个时间是固定的），那么时间缩短的百分比会更大。

1.3 传输中间件配置

以MQ为例，MQ作为传输中间件，qm.ini中也有相关的参数会影响到传输的效率，qm.ini示例如下，这里介绍几个典型的参数。

1）Buffer

Buffer相关的参数，如果=0，则交由操作系统的TCP/IP管理buffer大小，如果是非0，则MQ覆盖操作系统的配置。

SndBuffSize：通道的发送端发送buffer，可被特殊类型通道的参数（如RcvSndBuffSize）覆盖
RcvBuffSize：通道的接收端接收buffer，可被特殊类型通道的参数（如RcvRcvBuffSize）覆盖
RcvSndBuffSize：接收通道的发送端的发送buffer
RcvRcvBuffSize：接收通道的接收端的接收buffer
ClntSndBuffSize：客户端服务器模式下的客户端的发送buffer
ClntRcvBuffSize：客户端服务器模式下的客户端的接收buffer
SvrSndBuffSize：客户端服务器模式下的服务器端的发送buffer
SvrRcvBuffSize: 客户端服务器模式下的服务器端的接收buffer

听起来很繁琐，我们还是来个实例验证。
将Buffer（SndBuffSize、RcvRcvBuffSize）由32K调整成64K，对比4K小报文和1.2 MB大报文的影响。这里还是采用“报文从起点出发 -> 报文传输 -> 服务器A处理转发 -> 报文传输 -> 服务器B处理转发 -> 报文传输 -> 报文回到起点”的验证系统。

在处理大报文时，将MQBuffer由32K调整成64K，报文流转全流程时间减少32149.2毫秒或24.3%。

在处理小报文时，将MQBuffer由32K调整成64K，报文流转全流程时间较少4.9毫秒或5.8%。

增大TCP/IP的Buffer对于大报文的传输效率提升较为明显，对于小报文的传输效率提升不太明显。

2）通道压缩

针对某个通道，将其传输的报文进行压缩，对大报文来说，不但减少带宽的占用，而且提高了传输成功率。
alter chl(通道名) chltype(SDR) compmsg(ZLIBHIGH)
alter chl(通道名) chltype(RCVR) compmsg(ZLIBHIGH)

继续实例验证
在传输1.2M大报文时，开启MQ通道压缩后，网络带宽占用减少为原来的1/12，报文流转总时间减少255.0毫秒或11.9%。

在传输4K小报文时，开启MQ通道压缩后，网络带宽占用减少为原来的1/2（压缩比为2:1），报文流转总时间减少2.8毫秒或3.3%。

并且，服务器的CPU利用率增加非常小（例如：从16%增加到17.5%）。

3）通道批次BATCHSZ

由于MQ按照批次（BATCHSZ）的值进行提交和回滚确认(验证这一个批次是否都传输成功)，在传输过程中一旦出现问题，这个批次所有的报文都要重新传输。所以在网络不稳定的情况下(传输数据有丢失)，BATCHSZ设置的值越大，一个批次中有数据出错的概率就越大，重新提交传输的消息就越多，在有些情况下（尤其是大报文场景），甚至长时间不能完成一个批次的传输。

此时可以将每个传输批次改小，传输成功一个就确认一个，减少重传概率。

某大报文（1.2M）传输场景中，当传输批次=50时，传输效果如下，通道经常中断

将批次改为1之后的Network图形如下

二、 关注指标

2.1 LPAR占用的带宽

1. 获取来源

从网络设备上读取的带宽占用最准确，但网络设备往往连接多个主机，因此，从LPAR上读取自身占用的网络带宽是一个比较适用的方法。

Nmon：NET Sheet 
命令行topas：Network：BPS、B-In、B-Out

2. 详细解释

Nmon NET Sheet中找到实际对外通讯的网卡（例如en1），读取对应的en1-write（本机向外发送）、en1-read（本机收到）、en1-total。读数均为计算机的单位Byte，若转换为网络bps，需乘以8。

3. 观察带宽占用的意义

观察带宽占用情况，并结合CPU利用率等情况，可以帮助判断问题的原因出自哪里。如果怀疑到网络方面的原因，可以抓取tcpdump或者其他抓包工具进行深入分析，并检查相关网络设备。

假设系统的吞吐量下降了，或者吞吐量忽高忽低的抖动。

如果带宽占用中read下降，那么有可能是发送方没有将足够量的报文发送到本服务器。或者因为网络拥塞、通道异常等网络原因引起的接收报文吞吐量下降。

如果带宽占用中read基本没有变化，而write降低，那么有可能是本服务器处理报文的能力下降了，或者本服务器希望将报文发出去，但接收节点没有能力接收。

以下图为例，图中的网络流量有几个问题，1）有很多网络带宽占用率几乎为0的情况，2）有小部分时间段收到了报文数据，但并没有将他们处理后发出去，3）收到报文后并没有及时处理并将之发出，而是有一小段时间的延迟。

结合对应的CPU利用率的图形，可以推测
问题1）有很多网络带宽占用率几乎为0的情况

此时业务处理的吞吐量下降肯定不是有应用程序造成的，而是可能由于发送方没有将足够量的报文发送到本服务器。或者因为网络拥塞、通道异常等网络原因。

本案中进一步查看发送方，发送方有大量报文堆积在发送队列，那么，说明是网络方面原因。进一步检查网络，ping包是没有问题的，而且两台服务器之间的探测是通畅的，而发送方与接收方之间的传输通道却异常中断。

本案中进一步分析通道中断的原因。发现传输大报文（比如1MB）的时候，非常容易复现本问题，而传输小报文则没有遇到过本问题。怀疑是因为MQ传输的批次太大并且报文也太大，叠加效果就是只要一个传输失败就触发了MQ的某个bug。

解决：将通道批次由50改为1，问题得到明显缓解。

问题2）有小部分时间段收到了报文数据，但并没有将他们处理后发出去。

可能是本服务器没有处理报文，或者本服务器已经处理，但发送时，对端节点不接收。

本案中查看发送通道、对端节点均没有异常，断定是应用程序没有正常处理报文。

问题3）收到报文后并没有及时处理并将之发出，而是有一小段时间的延迟。

在发送通道正常的情况下，这种情况几乎可以断定是本机应用程序的问题。

2.2 网络响应时间

多个系统交互共同完成一个交易时，交易的响应时间必然包含的网络传输时间。有时网络的传输效率低下或者不稳定，不仅降低交易的处理效率，有时甚至会导致交易的失败（很多交易有超时机制）。

查看网络是否正常，通常采用ping命令查看ping的延时是否在合理范围，是否有丢包现象。

在局域网当中，ping延时0~1ms为正常，超过10ms时需要关注网络问题。
在广域网中，ping延时30ms内为正常。

有些交换机对ping命令设置了较低的优先级，可能在回复、转发ping包的时候有延迟，因此ping的结果不一定能反映真实情况。如果需要更为精确的测量可以探针捕获从某服务器建立TCP连接时发送的SYN包后开始计时起，到其收到对端发回的TCP SYNACK后的时间差。

如果采用专业的网络设备进行捕获，不但不影响服务器本身的性能，并且可以区分出哪一段网络延时较大。