本文探讨了iSCSI连接存储时遇到的读性能问题，问题根源在于TCP Delayed-Ack机制。当网络拥塞时，存储端保守的TCP重传策略与主机端的Delayed-Ack结合，导致了严重的吞吐量下降。大块读取或单线程应用更容易触发此问题，解决方案是禁用主机的Delayed-Ack，但这可能增加非存储网络的拥塞风险。
不知道你是否遇到过这样的情况，主机iSCSI连接存储，然后读性能不太好，找support，他们第一件事就是叫你禁用TCP Dealyed-Ack。不论你是ESX/ESXi、Windows、Linux/Unix，第一板斧就是这个。iSCSI和TCP Delayed-Ack有何深仇大恨，非要弄到不是你死就是我亡的地步。
我先简单介绍下Delayed-Ack：TCP为了保证可靠性，每个发出的分段都必须有Ack，为了减少网络上的Ack，TCP做了优化，在收到一个分段之后不会立刻就返回Ack，而是会启动一个timer，在timer超时之前如果再次收到一个分段，或者接收端有数据需要返回给发送端时，接收端的TCP会立刻返回Ack。如果这两种条件都不满足，那么必须等待timer超时才会返回Ack，大部分OS的TCP实现都是200ms。这个机制就叫Delayed-Ack。
好，那Delayed-Ack为什么会严重影响读性能？其实这里有个前提，那就是网络已经拥塞了。拥塞对于TCP来说，实质上大部分情况就是出现丢包了，于是TCP会触发恢复机制（slow start -> congestion avoidance），简单来说，就是会降低数据发送速率，为网络（交换机、路由器等设备清buffer）提供足够的时间来恢复正常&
最低0.47元/天 解锁文章
扫一扫
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
