使用基于NFS協(xié)議存儲系統(tǒng)的同學(xué)經(jīng)常遇到的問題是在小文件比較多的情況下性能會比較差。小文件訪問性能差本身是可以理解的，但是NFS確實(shí)是太差了。不知大家是否深層次分析過，為什么NFS訪問小文件性能會這么差？

NFS文件系統(tǒng)與本地文件系統(tǒng)的差異在于多了一個(gè)網(wǎng)絡(luò)傳輸?shù)倪^程。因此，我們從網(wǎng)絡(luò)傳輸方面下手，看看能不能獲取一些線索。為了能夠捕獲協(xié)議的數(shù)據(jù)，我們向共享目錄寫入一個(gè)文件(本例為tgt.c，可以根據(jù)情況改變文件名稱)，具體命令如下所示。

dd if=tgt.c of=/mnt/test/sub1/sub2/sub3/sub4/sub5/test bs=1024 count=2

如下圖是通過Wireshark抓取的網(wǎng)絡(luò)通信的數(shù)據(jù)包，可以看出，NFS在訪問文件的時(shí)候客戶端與服務(wù)端有的交互除了WRITE之外，還有很多其它的交互，包括ACCESS、LOOKUP和SETATTR等。并且可以看出，這些請求的數(shù)量跟目錄的深度是有關(guān)系，每一級目錄都會進(jìn)行LOOKUP和ACCESS操作，這就是NFS在訪問小文件的時(shí)候性能差的一個(gè)主要原因。

圖片

我們具體分析一下這個(gè)過程，稍微簡化一下，如圖所示?？梢钥闯觯瑢τ诿恳患壗M件（component），客戶端都會發(fā)送一個(gè)LOOKUP指令和一個(gè)ACCESS指令。這兩個(gè)指令是干什么的呢？

圖片

我們可以看一下協(xié)議文檔，以NFSv3為例，其文檔為RFC1813。如下圖是LOOPUP例程的功能描述，通過該描述可以看出LOOKUP的功能是按照名稱搜索目錄中的項(xiàng)目，成功的情況下返回一個(gè)句柄。從功能描述來看，這個(gè)指令也是很必要的，我們在訪問一個(gè)文件的時(shí)候，顯然必須要確保路徑是真是存在的。所以，客戶端要針對每一個(gè)組件發(fā)送一條LOOKUP指令來確保整條路徑的存在性。

圖片

另外一個(gè)指令是ACCESS，該指令的描述如下圖所示，其主要作用時(shí)確認(rèn)訪問的權(quán)限。也就是當(dāng)我們訪問文件的時(shí)候，客戶端需要向服務(wù)端逐組件的確認(rèn)該用戶是否有權(quán)限訪問當(dāng)前目錄。如果沒有相應(yīng)的權(quán)限，當(dāng)然不允許訪問了。

具體的權(quán)限很多，如協(xié)議中的定義，包括讀、查詢、修改、擴(kuò)展、刪除和執(zhí)行等操作。服務(wù)端會進(jìn)行權(quán)限的確認(rèn)操作，如果確認(rèn)失敗則客戶端會禁止應(yīng)用的訪問請求。所以，對于一個(gè)長路徑進(jìn)行逐級的確認(rèn)也是必須的。

圖片

由上述分析可以看出，對于一次寫操作，客戶端文件系統(tǒng)需要經(jīng)過與服務(wù)端10多次的通信交互，訪問性能自然會差很多。基于上述分析，如果向提升性能，顯然應(yīng)該減少客戶端與服務(wù)端交互的次數(shù)。如果能夠絕對信任服務(wù)端的文件路徑，一個(gè)最直接的方法是修改客戶端的邏輯，避免多級查詢。但是這種方法門檻有點(diǎn)高，而且有一點(diǎn)的隱患。在不修改代碼的情況下，我們可以遵循如下原則來一定程度上提升性能。

核心原則是減少客戶端與服務(wù)端的交互次數(shù)，因此我們在訪問文件的時(shí)候應(yīng)該盡量保持文件的打開狀態(tài)，避免重復(fù)打開關(guān)閉文件，這樣NFS全路徑的逐級檢查。這種方法對NFSv4以后的版本適用，但對于NFSv3及以前的版本并不適用，因?yàn)樗麄兪菬o狀態(tài)的。即使你在客戶端不關(guān)閉文件，在服務(wù)端訪問完數(shù)據(jù)后也是關(guān)閉的。

減少目錄層級，前面描述已經(jīng)很清楚了。NFS會檢查每一級目錄，而且每一級目錄的檢查需要客戶端與服務(wù)端交互至少2次。如果我們盡量減少目錄層級，那么可以最大化的降低客戶端與服務(wù)端交互的次數(shù)。

避免超大目錄，也就是一個(gè)目錄中文件的數(shù)量不要太多。服務(wù)端的有些文件系統(tǒng)變量目錄像的效率并不高，當(dāng)目錄項(xiàng)太多時(shí)，查找將非常耗時(shí)。

盡量使用大文件，而非小文件。似乎這個(gè)并不好實(shí)現(xiàn)，因?yàn)槲募拇笮∈菢I(yè)務(wù)決定的，我們似乎很難控制文件的大小。但是，如果是自己開發(fā)的應(yīng)用程序， 在保存數(shù)據(jù)的時(shí)候盡量以大文件的形式，而非小文件的形式，這對性能是有益的。

回頭想一下，NFS的性能問題很早就暴露了，難道NFSv4、NFSv4.1和NFSv4.2發(fā)展這么多年就沒有解決嗎？我們后續(xù)會分析更新版本NFS協(xié)議，看看他們在性能方面做了哪些優(yōu)化。