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

一、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）收到报文后并没有及时处理并将之发出，而是有一小段时间的延迟。

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

二、网络响应时间

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

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

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

在广域网中，ping延时30ms内为正常。

 

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

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