http://www.lichaozheng.info/2011/10/13/nfs%E6%80%A7%E8%83%BD%E4%BC%98%E5%8C%96/#sec-12
Table of Contents
1 NFS概述
NFS：Network file system，網絡文件系統.由sun公司1984年推出，用來在網絡中的多臺計算機間實現資源共享(包括象文件或cd-rom).設計的目的是：實現在不同系統間交互使用，所以它的通信協議採用與主機和操作系統無關的技術
NFS Server可以看作是File Server，它可以讓你的PC通過網絡將遠端得NFS SERVER共享出來的檔案MOUNT到自己的系統中，在CLIENT看來使用NFS的遠端文件就象是在使用本地文件一樣.
NFS協議從誕生到現在有多個版本： NFS V2（rfc1094）, NFS V3（rfc1813）(最新的版本是V4(rfc3010))
如何查看nfs當前的版本：
rpm -qi portmap
rpm -qi nfs-utils
2 設置NFS讀寫塊大小，優化傳輸速度
在客戶端中有兩個掛載選項——rsize和wsize——來設定客戶端和服務器間來回的數據包大小。如果沒有設定默認的rsize和wsize一般是4K(4096 byte)。理論上，NFS v2的最大塊大小是8K，但是NFS v3最大的是32K(32*1024 byte)（over TCP）或者64K（over UDP），在linux服務端上，最大的塊大小定義在內核的源文件./include/linux/nfsd/const.h中的NFSSVC_MAXBLKSIZE。根據不同的需要，默認值可能太大或者太小。這就需要通過不斷的實驗調整rsize和wsize。
首先是在客戶端寫文件，設定文件塊爲32K，共寫入16384個文件塊，文件大小爲32K*16384
# time dd if=/dev/zero of=/mnt/home/testfile bs=32k count=16384
然後是在客戶端讀文件，文件大小一般要是內存大小的兩倍,以保證不被內存緩衝機制所緩衝
# time dd if=/mnt/home/testfile of=/dev/null bs=16k
這樣重複幾次取平均值。在每次測試前記得在客戶端重新掛載文件系統，這樣能清除緩衝。
然後，換更大或者更小的塊大小。要保證塊大小是1024的整數倍，並且不能超過NFS最大的系統塊大小限制。不論*NFSSVC_MAXBLKSIZE*定義的是多少，NFS Version 2最大的塊大小都是8K；Version 3可以允許最大支持64K（over UDP），文件的塊大小必須是2的冪。儘管如此，一些用戶也報告說可以不是2的冪，但也是文件系統和網絡包大小的整數倍。
掛載更大的塊以後，cd進掛載的文件目錄，執行ls命令，確保一切正常。如果rsize/wsize太大，系統就會表現得很奇怪並且不能100%的顯示命令輸出。一種典型的現象就是，執行ls命令後，不能顯示完整的文件列表，擯棄沒有任何的錯誤嘻嘻，或者沒有任何錯誤提示的情況下讀文件失敗。在指定好rsize/wsize以後，可以再次測試速度。
通常的做法都是在/etc/fstab中指定rsize/wsize的大小：
# echo "foo:/tmp /mnt/foo nfs rw,hard,intr,rsize=8192,wsize=8192 0 0"
>> /etc/fstab
# mkdir /mnt/foo
# mount /mnt/foo
3 網絡包大小和網卡驅動
大部分的linux網卡驅動是正常的，但是總有少數有問題。有問題的時候可以嘗試升級驅動程序，來看看是否能解決問題。先使用ping back的命令
#ping -f #ping -s
如果有很多丟包或者長時間的響應，就很有可能是網卡的問題了
除此以外，還用nfsstat分析NFS的流量，客戶端和服務器統計，網絡統計。選項“-o net”可以顯示丟包的數目。在UDP傳輸中最重要的統計項是重傳數——可能是由於丟包，socket緩衝移出，超時等情況引起。這些都會嚴重影響NFS性能，必須仔細檢查。
PS：nfsstat不再支持參數“-z”（把nfsstat的統計清零），所以得留意之前的nfsstat統計值
爲了糾正網絡問題，有時候需要重新配置網卡的默認IP包大小。經常會發生路由的最大IP包大小比網卡的小。TCP協議可以自適應，但是UDP協議不行（會導致分片丟包，然後重傳）。所以NFS over UDP特別要注意設置MTU的大小。可以用命令*tracepath*來看網絡上的MTU值，用ifconfig命令來看網卡的MTU值，要使兩者匹配。
4 網絡包分片導致的溢出
當rsize/wsize大於網絡的MTU（大部分網絡都是1500，除非設置了支持大包）時，IP包在用UDP協議傳輸時會分片。大量IP包分片會消耗網絡兩端大量的CPU資源，而且還會導致網絡通信更不穩定（因爲完整的RPC在UDP分片的任何一個包丟失時都得整個RPC重傳）。任何RPC的重傳增加都會導致時延的增加。這是NFS over UDP性能的最大瓶頸。
如果你的網絡拓撲很複雜，UDP的分片包的路由很可能不同，可能不會都及時到達服務器。內核對分片包的緩存有限制，最大值由ipfrag/_high_thresh指定。可以查看文件/proc/sys/net/ipv4/ipfrag_high_thresh和/proc/sys/net/ipv4/ipfrag_low_thresh。一旦未處理的包數目超過ipfrag_high_thresh，內核就會丟棄分片包，直到數量達到ipfrag_low_thresh
另一種監視的方法是文件/proc/net/snmp中的IP：ReasmFails。這是分片組合失敗的數量，如果這個值在大量文件傳輸過程中上升太快，就有可能是有上述問題。
5 使用NFS over TCP
NFS over TCP 是 2.4和2.5內核的新特性。和UDP相比有不同的優缺點。
- 優點是在低可靠性的網絡中的性能優於UDP。一旦丟包只要重傳一個包而不是整個RPC。另外，TCP在不同網速的網絡中可以自協調速度，性能也會比UDP好。
- 缺點是TCP是可靠連接協議，如果在包的傳輸過程中服務端奔潰了，在客戶端需要重新掛載
6 超時和重傳值
NFS over UDP 中有兩個選項 timeo 和 retrans ，分別控制超時和重傳數。其中timeo的單位是0.1s，默認值是0.7s。retrans是超時後重傳的次數，默認值是3。重傳時會顯示消息
Server not responding
一旦客戶端顯示這個消息，客戶端就會重新發起請求。如果這時正好另一個超時發生了，客戶端就會先處理更近的超時錯誤，處理結束後再接着處理這個超時。如果處理成功則會顯示消息
Server OK
7 守護進程NFSD的個數
大部分的默認情況下，linux或者其它操作系統都會啓動8個NFSD。這個數字是在NFS早期由Sun公司的一個經驗法則。後來其它人就沿襲下來了。沒有什麼好方法來確定究竟多少個NFSD纔是最優的，但是更大的負載可能需要更多個NFSD。雖然你應該一個處理器至少有一個NFSD,但是每個處理器8個可能是比較好的經驗法則。如果你的內核是2.4以上，並且你想看看每個NFSD 線程的負載情況，你可以看文件/proc/net/rpc/NFSD。文件中th行的最後的10個數說明線程的負載的百分比對於時間的直方圖（第一個數代表運行的NFSD 數，第二個數代表所有線程需要的時間，後面的就是那一時刻的所需時間/最大允許時間）。如果後面的幾個數加速增加了，那麼你的服務端就得要更多的NFSD 線程。
修改NFSD 線程數是在 /etc/rc.d/init.d/nfs 中的RPCNFSDCOUNT值。記得重啓服務。
8 輸入隊列的內存限制
在2.2和2.4內核中，默認的socket讀緩存rmem_default是64k，寫緩衝wmem_default是8k。這兩個值對有大量讀寫負載的情況很重要。
許多公開的對NFS的測評多使用大得多的讀寫緩存[rw]mem_default和[rw]mem_max。可以考慮增加這些值到256k。按下面的方法做比較安全(以讀緩衝爲例)
- 在文件中增加值
# echo 262144 > /proc/sys/net/core/rmem_default # echo 262144 > /proc/sys/net/core/rmem_max
- 重啓NFS(Redhat環境)
# /etc/rc.d/init.d/nfs restart
- 測試結束後恢復正常值
# echo 65536 > /proc/sys/net/core/rmem_default # echo 65536 > /proc/sys/net/core/rmem_max
9 關閉網卡和集線器的自動協商協議
如果網卡和hub與交換機自協商異常並且運行在不同的速度上，或者處在不同配置的雙工模式下（全雙工、半雙工），那麼性能會因爲過多衝突或丟包等受到嚴重的影響。如果可能，儘量在100M全雙工內網傳輸，這樣可以爲NFS over UDP消除大部分的網絡。當關閉網卡自適應時，要注意項鍊的hub或者交換機將重置到其它雙工設置，並且一些網卡爲了支持老hub默認是半雙工的。最好的解決方法是強制網卡爲100M全雙工。
10 NFS的同步和非同步選項
NFSD v2 和 v3協議默認的是非同步的。非同步默認讓服務端不等把數據寫入本地磁盤就響應客戶端請求。在服務端“exportfs -av”出的列表中可以看到async選項。雖然有可能在服務端仍然有未寫入的數據時服務器重啓會導致數據丟失的代價，但是非同步的性能更好。當發生上述情況時不能被檢測到，因爲“async”選項指示服務器欺騙客戶端，讓它以爲所有的數據確實都寫入磁盤了，而不考慮協議是怎樣做的。
當使用同步選項時，NFS v2將等到所有的數據都寫入磁盤以後才響應請求；NFS v3則不同，它會返回狀態來高數客戶端什麼數據仍然在緩衝中和什麼數據可以安全的丟棄。狀態有三種值，定義在include/linux/nfs.h的nfs3_stable_how字段：
- NFS_UNSTABLE 在服務端數據還沒寫入磁盤，必須在客戶端緩衝數據，除非隨後客戶端提交請求確認服務端已經把數據寫入磁盤了
- NFS_DATA_SYNC 數據還沒完全寫入，必須在客戶端緩衝。這時必須返回上面說的請求
- NFS_FILE_SYNC 沒有數據需要被緩衝這時不需要返回
除此以外，當服務端使用同步選項，客戶端如果打開文件的時候使用O_SYNC選項,客戶端都會堅持等把數據寫入磁盤以後再響應其它請求。這種情況下，從客戶端來看NFS v2 和v3 的性能看起來都是一樣的。
如果在服務端設定非同步，那麼O_SYNC選項將不起作用，因爲服務端不等數據完全寫入磁盤就馬上響應。v2和v3版本間無差異。
最後，當NFS v3 使用同步選項並且當文件關閉或者fsync()的時候，將強制服務器把所有緩衝中的數據寫入磁盤才響應客戶端請求。如果使用非同步選項，這個請求沒有任何作用。
11 和NFS無關的提高服務器性能的方法
通常來說，服務器的性能和磁盤服務的性能也會嚴重影響NFS的性能。一下幾點有必要考慮：
- 如果使用RAID陣列，用RAID 1/0可以保證寫速度和冗餘；RAID 5有比較好的讀速度但是會降低寫速度
- journalling 文件系統會減少重啓時間。目前ext3已經可以正確的和NFS v3。另外，Reiserfs v3.6可以在2.4.7或者更高的內核上和NFS v3 一起工作。Reiserfs更早版本會有問題
- Additionally, journalled file systems can be configured to maximize performance by taking advantage of the fact that journal updates are all that is necessary for data protection. One example is using ext3 with data=journal so that all updates go first to the journal, and later to the main file system. Once the journal has been updated, the NFS server can safely issue the reply to the clients, and the main file system update can occur at the server’s leisure.
The journal in a journalling file system may also reside on a separate device such as a flash memory card so that journal updates normally require no seeking. With only rotational delay imposing a cost, this gives reasonably good synchronous IO performance. Note that ext3 currently supports journal relocation, and ReiserFS will (officially) support it soon. The Reiserfs tool package found at ftp://ftp.namesys.com/pub/reiserfsprogs/reiserfsprogs-3.x.0k.tar.gz contains the reiserfstune tool, which will allow journal relocation. It does, however, require a kernel patch which has not yet been officially released as of January, 2002.
- 用自動掛載（比如autofs或者amd）可以在機器down以後自動掛載。
- 一些廠商（Network Appliance, Hewlett Packard或者其它）用NVRAM提供NFS加速。NVRAM提高訪問速度到async的訪問速度
12 文件屬性與目錄屬性的更新時間
在NFS中如果需要提高實時性，還有一組非常容易忽略的參數
- acregmin=n：設定最小的在文件更新之前cache時間，默認是3
- acregmax=n：設定最大的在文件更新之前cache時間，默認是60
- acdirmin=n：設定最小的在目錄更新之前cache時間，默認是30
- acdirmax=n：設定最大的在目錄更新之前cache時間，默認是60
- actimeo=n：將acregmin、acregmax、acdirmin、acdirmax設定爲同一個數值，默認是沒有啓用。
- noac: 關閉cache機制。
新建和刪除文件屬於修改目錄屬性；增加和修改文件屬於文件屬性。
在抓包測試中發現，當客戶端讀文件屬性的時候，NFS的工作方式是nfs客戶端直接給出cache的文件屬性。而服務端最快每隔acregmin更新一次文件屬性，每隔acdirmin更新一次目錄屬性。因此就算在局域網的理想條件下，也常常會有其實文件或目錄已經更新,在NFS客戶端卻無法及時看到更新的假象。
Date: 2011-10-13 19:25:34
HTML generated by org-mode 6.33x in emacs 23
