aix系统运维案例（一）：AIX网络性能问题

故障描述

业务系统两个节点中的一个节点性能缓慢，登陆后执行命令的响应非常缓慢，对该节点的IP地址做ping操作发现RTT的时间一直持续在200ms以上。停止应用程序后问题得到缓解，但是重启应用后问题重现。在重启服务器后，通过负载均衡器将负载逐渐恢复到原有水平后，问题得到很大缓解，应用能够正常运行，但是ping还是有不定时的较大延时，个别时间会出现超过100ms的延时。

系统环境

AIX 5.3 TL11 SP3

故障分析

分析IP trace，可以看到两个节点之间的ping有延时。延时从0ms到99ms不等，平均的delay时间在20ms。通常在局域网内，同网段的IP互相ping的正常延时一般都在1ms以内。如下是从IP trace里抓取到的ping包

分析netstat -an的输出，可以看到处于半连接状态(SYN_RCVD)的TCP连接数非常多，达到了5217，并且所有的半连接都是针对http监听端口80。

半连接状态表示TCP还没有完成socket的三次握手过程。也就是说当HTTP服务器端收到来自客户端的连接请求(SYN)后，向客户端发送了SYN|ACK包，然后就会处于SYN_RCVD状态，等待来自客户端的ACK包。如果客户端的ACK包能及时到达服务器端，这个TCP连接状态就会从SYN_RCVD变为ESTABLISH，也就是完成了连接建立的全过程。但是，在出现问题的两个主机上，可以看到大量的SYN_RCVD连接数，并且占到了TCP连接数的绝大部分，说明大部分连接都没有接收到来自客户端的ACK包。服务器端iptrace的分析结果也证明了这一点，如下所示：

从m.n.99.132(负载均衡器)到x.y.18.82，可以看到SYN包发出，Sequence Number是703222932, 因此它期待的回包应该是ACK Number为703222933的SYN|ACK包。

可以看到从x.y.18.82到负载均衡器的SYN|ACK包已发出，ACK Number是703222933，接下来应该期待Sequence Number为703222933, ACK number为4163094494的包，但是却一直没有收到。于是TCP重传了该SYN|ACK包，重传4此后，受到了来自负载均衡器的地RST|ACK包。如下所示：



对于HTTP服务器来说，由于负载均衡器屏蔽了实际客户端的IP地址，因此我们只能够从iptrace里看到半连接状态是由于服务器端没有来自来自负载均衡器的ACK包。造成这个问题的原因可能是客户端在收到SYN|ACK后没有发出ACK包，或者发出的ACK包在网络传输过程中被丢弃，也有可能是负载均衡转发的来自服务器端的SYN|ACK在网络传输过程中被丢弃。具体的原因需要在网络上进行抓包分析，从而确定造成ACK丢失的根源。根据目前网络抓包分析的进展，问题应该出在客户端。
对于ping延时的问题，目前怀疑和某个global resource的竞争有关。抓取的多个kernel trace并没有显示有锁竞争存在，但是由于抓取kernel trace的时候ping的延时已经有很大的改善，从出现故障时的400ms到当时平均的20ms左右，所以锁的竞争并不明显，导致kernel trace没有抓取到。

故障建议

1) 在AIX上设置如下两个参数。
tcp_keepinit = 10
clean_partial_conns = 1
tcp_keepinit缺省是150(75秒)，将其设置为10(5秒)可以确保TCP半连接的状态只能最多持续5秒钟，这样就不会导致大量的半连接状态积压。clean_partial_conns设置为1，可以确保当TCP连接数达到qlimit的限制后，系统会自动清除一些半连接，从而确保新的TCP连接可以建立。
2) 建议将somaxconn从目前的8192小，比如4096，这样一旦对某个端口的TCP连接数超过4096，系统就可以自动清除半连接，避免因为积累过多的半连接造成网络整体的性能下降。