超棘手：做好NAS存储性能优化

2. rsize和wsize,每次读写的最大值。该值对性能的影响和CIFS的第二点是一样的，所以不再赘述。

3. sync和async,sync意味着服务器需要把数据写到磁盘再确认；async则意味着服务器可以把数据存到cache里就确认，然后再慢慢把cache里的数据刷进磁盘。有一个经常被忽视的严重问题：sync参数会强制wsize变成4KB,这会大大降低写性能。

本文介绍的几种优化方式，比如启用SMB2,增加rsize等，除了它们本身能优化性能，还能提高传输层的性能。

为了检验"叫外卖"的方式能提高多少效率，他在NAS和作为客户端的Windows 7上都启用了smb2,果然看到读写性能大幅度提升。

熟悉网络的读者可能会存疑：在局域网里的往返时间（RTT）很短，读写的总时间其实大多消费在服务器的响应上。smb2的改进看起来只节省了RTT,可能达到大幅度提升（比如数倍）的效果吗？这个质疑完全正确，但这位读者的实验结果也是真实的。怎么解释这个矛盾呢？答案就在TCP协议上。本文将详解TCP中影响NAS性能的各个因素，包括对以上矛盾的解释。

在逐条分析之前，先让我们复习一下TCP的重传机制，因为后面会多次谈及它。当有TCP包在网络上丢失时，TCP有两种机制来实现重传：超时重传和快速重传。下图展示了这两种情况：

图1, 发送方只给接收方传送了一个包。不幸的是这个包在网络上丢失了，所以发送方迟迟等不到来自接收方的确认。在经过一段时间（RTO）之后，发送方认为该包已经丢失了，所以重新传了一次。这个机制就是超时重传。RTO能达到数百毫秒，这在计算机世界可以算"浪费很长时间"了，NAS对一个读写请求的响应也就几个毫秒。除此之外，超时重传还会使TCP发送窗口降到最小，更是雪上加霜。如果网络中有超过0.1%的超时重传，我们就能看到明显的性能问题。减少超时重传对提高性能有明显的改善。

图2,发送方要给接收方传送5个包，不幸的是第一个就丢失了。由于这个发送窗口>=5个MTU,所以发送方在没有接收方确认的情况下继续发送了四个包。接收方在收到这些包的时候，可以通过包号知道第一个包丢失了。所以收到第n个时（n=2,3,4,5），接收方就发一个"收到n,但1还没收到呢"给发送方（如下图的红线所示）。发送方在收到四个"但是1还没收到呢"的消息后，意识到1可能已经丢失了，就赶紧重传一个。这个机制称为快速重传。由于这个过程没有等待时间，所以对性能影响较小。实现超时重传的条件是发送方在丢了一个包后，接下来还有4个或以上包可以传。