DataDomain发送一系列包给AIX，但是其中的一些包在路上丢了，没有到达AIX，如图中的Seq No.=0，从而导致重传。这说明之前在路上的猜测是正确的，根本原因是网络上的拥塞。
网络分析真有这么神奇？抓个包就能看到服务器，客户机甚至网络设备的性能瓶颈？事实的确如此，而且不仅能解决性能问题，连Kerberos验证出错，NFS挂载失败，NDMP备份中断等棘手问题都能够找出原因。更重要的是，无论你从事哪个行业，只要涉及网络，抓包分析都非常有用。上篇文章介绍的Isilon案例还属于NAS范畴，算是阿满的主业。今天要分享的是DataDomain的案例，这是以前从来没接触过的领域。
来找我的还是上篇文章中那位要帮我搬家的老板（我下个月还要再搬家，这次一定要叫他扛家具）。问题大概是这样的。客户有好几台AIX往DataDomain读写数据。写性能很好，能超过100MB/s。但读性能特别差，在20MB/s以下。网络拓扑不明，但知道一个小细节：AIX的网卡是千兆的，而DataDomain用的是万兆卡：
从五角场打车到唐镇花了好长时间。我得以在路上分析这个问题的成因：
1.一般存储都是读比写快，DataDomain应该也不例外。当前现象是读比写慢得多，那这个问题的原因应该不在DataDomain上。
2.网络很值得怀疑。写操作时数据从1G网络流向10G网络，如同小河水流入大河，自然是非常通畅。读操作时数据从10G网络流向1G网络，如同大河水流入小河，很可能导致拥塞，从而带来严重的性能下降。
中午11点多，终于见到了客户的网络管理员。我们打开在DataDomain和AIX上分别抓到的网络包，看到很多类似下图（图里只显示从DataDomain到AIX的包，另一个方向的被过滤了）的现象：DataDomain发送一系列包给AIX，但是其中的一些包在路上丢了，没有到达AIX，如图中的Seq No.=0，从而导致重传。这说明之前在路上的猜测是正确的，根本原因是网络上的拥塞。要彻底解决这个问题，能够把AIX端的网络升级到10G。但是客户明确表示，路由器和交换机已经没法动了，只能从DataDomain和AIX的配置上想办法。
明知问题出在网络上，却要到服务器和客户端去解决问题。是不是很有头痛医脚的感觉？但的确是可行的：
1.把DataDomain的发送窗口强制定义成一个很小的值。就像大河里流的水很少，到了小河也不会漫出来。问题是我们不知道多小的发送窗口最合适，因为多台AIX与此同时在读写，拥塞点很不稳定。我们一般不采用这个方法。
2. 仔细分析上图，其实丢掉的包只有Seq No.=0（因为AIX收到了1460-8760），但实际上1460-8760也重传了（相当于增加了6倍的重传率）。这是因为发送方发现某个包丢失后，无法确定（该包之后的）其他包是否也丢了，只好选择全部重传。接收方虽然有这些信息，但是没有办法告诉发送方。其实RFC2018在1996年已经给出了解决方案，就是Selective Acknowledgment，简称SACK。在接收方和发送方都启用SACK的情况下，接受方能够告诉发送方“我没受到0，但是收到了1460-8760”。这样发送方只要重传Seq=0即可。在启用SACK的情况下，我们看到的情况应该如下图所示：
检查发现AIX上果然没有启用SACK，所以我们只需要运行“no -p -o sack=1”打开就行了。效果和我预测的一样，读性能立即飙升到100MB/s以上。客户连声说，“这样算很好了！”
在他们询问我的名字前，我已经关上车门，只留下一个伟岸的背影，深藏功与名。心里只有一个怨念：下次再借我去现场，能不能把项目利润的1/10分给我？！！
声明： 此文观点不代表本站立场；转载须要保留原文链接；版权疑问请联系我们。
