無論是程序員，DBA還是網管，似乎所有的ITer都會遭遇同一問題：性能優化。NAS從業者也不例外，而且NAS的問題更加棘手，因為它所涉及的協議和設備很多。本系列博文將從共享協議入手，再到網絡，最后到NAS服務器本身，逐層分析NAS性能的影響因素。

　　NAS的共享協議，就是之前介紹過的NFS和CIFS。他們的讀寫方式總體相似，但是細節處又有不同。我們先來看CIFS(SMB)的工作方式。

　　當我們在Windows Explorer上打開一個128KB的文件時，底層的讀操作是這樣的：

　　1. 客戶端：我想讀某文件。

　　2. NAS： 你有權限，讀吧。

　　3. 客戶端：先讀64KB。

　　4. NAS：給你64KB。

　　5. 客戶端：再讀接下來的64KB。

　　6. NAS：給你64KB。

　　如果這個文件不只128KB，5和6就不斷重復，直至整個文件讀完。在這個過程中，影響性能的因素有：

　　1. 客戶端總是在收到上一個讀請求的回復后，再發送下一個請求。這其實是一種低效率的工作方式。就像某人今晚想吃肯德基的雞翅和漢堡，他先叫雞翅外賣，等雞翅送達后，再叫漢堡外賣。合理的方式是雞翅和漢堡外賣一起叫。在讀文件時體現為：

　　1. 客戶端：我想讀某文件。

　　2. NAS： 你有權限，讀吧。

　　3. 客戶端：先讀64KB。

　　4. 客戶端：再讀接下來的64KB。

　　5. NAS：給你64KB。

　　6. NAS：給你64KB。

　　由于3和4(兩個請求)，以及5和6(兩個回復)可以接連發送，所以節省了往返時間(如下圖所示)。SMB2的讀操作就是以這種方式工作的。為了優化性能，建議把Windows客戶端升級到Windows Vista或以上，然后啟用SMB2。

　　2. 客戶端每次讀的數據大小，也會影響到性能。在上面的例子中客戶端每次讀64KB，是一個比較好的數值。如果讀的值特別小(比如4KB)，會增加讀操作和往返次數，從而影響性能。這個值的大小是由客戶端和服務器協商決定的。客戶端上完全取決于應用程序，服務器上一般有設置選項。比如Windows服務器提供了SizReqBuf這個注冊表鍵值供用戶設置。

　　3. 另外一個性能影響因素是服務器的響應時間。對于讀操作，最常用的優化方式是啟用“prefetch”。即服務器在回復了前一個讀請求后，立即把接下來的數據從硬盤中讀出，等著回復下一個請求。

　　CIFS的寫操作和讀操作方式相似，對于相同點就不再贅述。不同點主要體現在響應時間的優化方式上。服務器為了優化寫操作的響應時間，一般采用write cache的方式。也就是服務器先把客戶端寫過來的數據存在cache里，然后向客戶端確認。接下來再慢慢把cache里的數據刷進磁盤。當然這種方式存在一定的風險，如果服務器突然斷電，cache里的數據就會丟失。客戶端的應用程序可以啟用write throuth來避免write cache。

　　下面，我們再看看NFS的工作方式。

　　和CIFS不同，NFS共享在使用前需要掛載(mount)。掛載時使用的參數很大程度上影響了讀寫的性能。列舉如下：

　　1. UDP或TCP：在網絡非常穩定的情況下，UDP理論上比TCP性能好一點，因為UDP包在協議上的消費比例低。但是如果有網絡包丟失，TCP就顯示出優勢。因為UDP包丟失時，整個讀/寫操作的所有包都要重傳；而TCP包丟失時，只需重傳丟失的那個包即可。

　　2. rsize和wsize，每次讀寫的最大值。該值對性能的影響和CIFS的第二點是一樣的，所以不再贅述。

　　3. sync和async，sync意味著服務器需要把數據寫到磁盤再確認；async則意味著服務器可以把數據存到cache里就確認，然后再慢慢把cache里的數據刷進磁盤。有一個經常被忽視的嚴重問題：sync參數會強制wsize變成4KB，這會大大降低寫性能。

　　本文介紹的幾種優化方式，比如啟用SMB2，增加rsize等，除了它們本身能優化性能，還能提高傳輸層的性能，我們將在下一篇博文中詳細介紹這一點。

原文鏈接：http://stor.zol.com.cn/292/2928925.html