【案例分享】：ping延时间歇性暴增

某业务系统的响应时间很不稳定，该系统有两类服务器构成，可以简单理解为A和B，A为客户端，B为服务端，A处业务的响应时间非常不稳定。

第一步：

从各类资源（CPU、内存、网络IO、磁盘IO）中追查原因。最终发现A与B直接的网络延时非常不稳定。A ping B，在局域网环境，按理说延时应该是0ms-1ms之间，而我们在业务高峰时发现，隔一小段时间就有100-200ms的延时出现。即使在没有业务的情况下，ping也30-40ms的延时。

第二步：

那么好，着手定位网络问题吧。

开始排查网路。换A的物理端口、换交换机、换网线、换对端的物理端口等等一系列措施之后，发现问题依然存在。

第三步：

采用网络探测设备，从交换机两侧端口抓包，分析一个tcp连接的建立过程时间消耗在哪里。分析后发现，200ms的延时，都是在B测。即一个tcp连接建立过程在A侧和交换机侧几乎没有什么时间消耗。

第四步：

B侧多台分区共用一个物理机。猜测是否是分区过多导致。当只有一个LPAR启动的时候，没有ping的延时，当启动一部分LPAR时候，延时较小，当所有LPAR均启动，ping 延时较大。

问题根因：

此时，问题水落石出，原来是由于分区过多导致了B回复A的ping有了延时。那么为什么会出现这种情况呢？一个物理机上CPU资源是有限的（本环境中是3颗），即使只有一个LPAR，其上面的N个进程也会去轮流使用CPU，何况此时是M台LPAR，M*N个进程去轮流使用这三个CPU，当然调度算法并不是这么简单，这里仅仅是从理论上做个说明。假设每个CPU时间片是10ms，那么极端情况下，一个进程要等到CPU需要等待（M*N-1）*10（ms）/3。

况且，这么多LPAR的进程轮询一遍CPU，CPU里面的cache 数据估计早就被挤走了，重新加载是比较耗时的。

应对方法：

之前LPAR也设置了保障的CPU（MIPS数量的保障），但只有数量没有质量（上述提到的CPU cache问题，即亲和性问题）

应对方法是：将重要的LPAR分配dedicated CPU，保证CPU资源的质量，保证轮询CPU的客户尽量少，这样CPU cache中的数据尽量不被清走。经验证，ping延时基本消失，方法有效。

本案例是一起看似是网络问题，但实际是资源调度方式的问题。

顺便提一句，很多情况下，客户端的响应时间不稳定都是由服务器端的服务能力不稳定造成的。一般情况下都是应用、数据库的问题造成。而本案例是操作系统层面答复ping出现间歇性延时，很容易误导我们的分析判断。