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

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

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

上面的思維導(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)整策略，有時(shí)候有一條策略就會(huì)導(dǎo)致NFS的網(wǎng)絡(luò)包被防火墻過濾，從而導(dǎo)致NFS的故障。五六年前我遇到過一個(gè)客戶的NFS故障，只要訪問一個(gè)文件NFS就會(huì)HANG死，訪問其他文件就啥事沒有。當(dāng)時(shí)實(shí)在沒辦法了只能用網(wǎng)絡(luò)抓包的方式去跟蹤，最后發(fā)現(xiàn)客戶最近上了一個(gè)敏感詞過濾的策略，因?yàn)檫@個(gè)文件名帶有敏感詞匯，因此網(wǎng)絡(luò)就丟包了。

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

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

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

實(shí)際上NFS HANG的問題分析因?yàn)樯婕暗脑蚝芏啵酝€是不容易定位的，不過如果df命令hang，而且是可重現(xiàn)的，那么分析起來還是有方法的。最好的防范就是使用strace去跟蹤df命令的堆棧?？纯磆ang在什么地方，就比較容易定位問題了。

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