昨天有個朋友咨詢一個問題，他通過NFS MOUNT了一個分布式文件系統(tǒng)，發(fā)現(xiàn)對這個文件系統(tǒng)df的時候經(jīng)常hang死，他檢查了一番系統(tǒng)，發(fā)現(xiàn)內(nèi)存使用率很高，大部分物理內(nèi)存都被cache占用了。他想通過分析cache中都有哪些數(shù)據(jù)，通過這個分析來確認cache占用率高和NFS hang之間是否存在關(guān)聯(lián)關(guān)系。當時我的建議是首先不要把問題直接定位到OS內(nèi)存上，如果系統(tǒng)不存在嚴重的SWAP，哪怕物理內(nèi)存使用率達到98%，也是關(guān)系不大的。

實際上使用NFS文件系統(tǒng)，出現(xiàn)客戶端hang死，或者df命令HANG死的情況并不少見，我這些年里也遇到過多次。我遇到的NFS hang死問題的原因也十分復(fù)雜，不過大多數(shù)都與NFS BUG、網(wǎng)絡(luò)問題、系統(tǒng)資源消耗過高、IO負載過大等有關(guān)。

NFS客戶端訪問NFS文件hang住，一般來說有三種可能性，一種是客戶端出現(xiàn)問題，第二種是服務(wù)端出現(xiàn)問題，第三種是客戶端和服務(wù)端都存在問題。似乎這個總結(jié)有點太籠統(tǒng)了，也有點投機取巧，不過窮舉法是我們在針對未知問題分析的最重要的方法。如果我們不能窮舉所有的可能性，那么在問題診斷分析的時候就可能無法定位。在我多年的經(jīng)驗里，很多當時認為十分靈異的問題，都是因為我們以前的知識面不足，無法窮舉到真正的故障路徑。

上面的思維導(dǎo)圖是我這些年遇到過的一些NFS HANG的情況，其中遇見最多的還是和網(wǎng)絡(luò)有關(guān)的，自從NFS V3/V4版本之后，NFS或者OS自身BUG導(dǎo)致的問題逐漸減少，而網(wǎng)絡(luò)方面遇到的問題逐漸變多起來。特別是防火墻問題，最近五六年里，我遇到的大型系統(tǒng)中的NFS問題大部分和防火墻有關(guān)。隨著企業(yè)對網(wǎng)絡(luò)安全的要求越來越高，防火墻也不斷地在調(diào)整策略，有時候有一條策略就會導(dǎo)致NFS的網(wǎng)絡(luò)包被防火墻過濾，從而導(dǎo)致NFS的故障。五六年前我遇到過一個客戶的NFS故障，只要訪問一個文件NFS就會HANG死，訪問其他文件就啥事沒有。當時實在沒辦法了只能用網(wǎng)絡(luò)抓包的方式去跟蹤，最后發(fā)現(xiàn)客戶最近上了一個敏感詞過濾的策略，因為這個文件名帶有敏感詞匯，因此網(wǎng)絡(luò)就丟包了。

實際上IP存儲專網(wǎng)建設(shè)十分重要，關(guān)鍵系統(tǒng)使用NFS的時候一定要使用IP存儲專網(wǎng)，最好不要經(jīng)過防火墻，不過很多大企業(yè)對于跨機房訪問的網(wǎng)絡(luò)安全管理十分變態(tài)，防火墻是必須要經(jīng)過的，一個NFS訪問經(jīng)過至少兩個防火墻，一旦網(wǎng)絡(luò)安全管理員與存儲管理員之間沒有很好的溝通，那么因為防火墻導(dǎo)致的NFS問題那就少不了了。另外我們以前遇到的大多數(shù)NFS故障場景都沒有使用IPSAN專網(wǎng)，NFS使用的網(wǎng)絡(luò)是和業(yè)務(wù)網(wǎng)混合使用的，業(yè)務(wù)網(wǎng)出現(xiàn)的任何問題，都會引起NFS文件系統(tǒng)的抖動，從而導(dǎo)致NFS服務(wù)不穩(wěn)定。

是否Socket hang的問題可以通過netstat命令來看是不是存在大量的TCP連接處于CLOSEWAIT狀態(tài)，如果存在這種情況，那么很可能你遇到了socket hang。Socket hang大多數(shù)和IO負載過高、客戶端或者服務(wù)器端OS相應(yīng)慢或者某個OS bug有關(guān)。也可能和TCP的keepalive參數(shù)設(shè)置有關(guān)。

另外一點是我們是用NFS的環(huán)境中，可能還安裝了數(shù)據(jù)庫服務(wù)器、中間件服務(wù)器等，這些系統(tǒng)要求調(diào)整OS的網(wǎng)絡(luò)參數(shù)，而這些參數(shù)的調(diào)整很可能并不適合NFS服務(wù)。其中常見存在沖突的幾個參數(shù)如下：

• lnet.ipv4.tcp_keepalive_time
• lnet.ipv4.tcp_keepalive_intvl
• lnet.ipv4.tcp_keepalive_probes
• lnet.ipv4.tcp_tw_recycle = 0
• lnet.ipv4.tcp_tw_reuse = 0
• lnet.ipv4.tcp_retries1 = 3
• lnet.ipv4.tcp_retries2 = 15

實際上NFS HANG的問題分析因為涉及的原因很多，所以往往還是不容易定位的，不過如果df命令hang，而且是可重現(xiàn)的，那么分析起來還是有方法的。最好的防范就是使用strace去跟蹤df命令的堆棧?？纯磆ang在什么地方，就比較容易定位問題了。

最后要說明的是，messages日志是一定要首要分析的，不管是客戶端還是服務(wù)端的messages日志都應(yīng)該盡早去看。雖然說很可能我們看到的只是NFS命令超時這類的比較籠統(tǒng)的信息。