未解决
此帖子已超过 5 年
107 消息
0
1707
另一个性能调优案例
《NAS性能调优实例》被几个网站转载后，有读者留言：网络分析真有这么神奇？抓个包就能看到服务器，客户机甚至网络设备的性能瓶颈？事实的确如此，而且不仅能解决性能问题，连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分给我？！！
bairichard1
107 消息
0
2012年8月28日 19:00
一般的服务器都启用SACK。AIX很特殊，不知道是啥目的。
baiRichard
50 消息
0
2012年8月28日 19:00
那是否by default就该启用SACK。看起来好像没什么副作用。
Yanhong1
1.6K 消息
0
2012年8月28日 20:00
我来解答一下，这个其实有个权衡问题。虽然SACK对吞吐量有好处，但处理这种acknowledge也对发送方的CPU造成较大的负担。所以可能会被人利用来进行一些网络攻击。下面一段是一个老外的回答：
A basic TCP ACK says "I received all bytes up to X." Selective ACK allows you to say "I received bytes X-Y, and V-Z."
So, for instance, if a host sent you 10,000 bytes and bytes 3000-5000 were lost in transit, ACK would say "I got everything up to 3000." The other end would have to send bytes 3001-10000 again. SACK could say "I got 1000-2999, and 5001-10000" and the host would just send the 3000-5000.
This is great over a high bandwidth, lossy (or high delay) link. The problem is that it can cause severe performance issues in specific circumstances. Normal TCP ACKs will make the server treat a high-bandwidth, lossy connection with kid gloves (send 500 bytes, wait, send 500 bytes, wait, etc). SACK lets it adapt to the high delay because it knows exactly how many packets were actually lost.
Here is where bad things can happen. An attacker can force your server to keep a massive retransmission queue for a long time, then process that whole damn thing over and over and over again. This can peg the CPU, eat up RAM, and consume more bandwidth than it should. In a nutshell, a lightweight system can initiate a DoS against a beefier server.
If your server is robust and doesn't serve large files, you're pretty well insulated against this.
If you're mostly serving an intranet or other low-latency group of users, SACK buys you nothing and can be turned off for security reasons with no performance loss.
If you're on a low-bandwidth link (say 1Mbps or less as a completely arbitrary rule of thumb), SACK can cause problems in normal operations by saturating your connection and should be turned off.
Ultimately, it's up to you. Consider what you're serving, to whom, from what, and weigh the degree of your risk against the performance effects of SACK.
想看再详细一些的话可以看
Performance tradeoffs of TCP Selective Acknowledgment