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

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

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

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

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

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

另外一點(diǎn)是我們是用NFS的環(huán)境中，可能還安裝了數(shù)據(jù)庫(kù)服務(wù)器、中間件服務(wù)器等，這些系統(tǒng)要求調(diào)整OS的網(wǎng)絡(luò)參數(shù)，而這些參數(shù)的調(diào)整很可能并不適合NFS服務(wù)。其中常見(jiàn)存在沖突的幾個(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的問(wèn)題分析因?yàn)樯婕暗脑蚝芏?，所以往往還是不容易定位的，不過(guò)如果df命令hang，而且是可重現(xiàn)的，那么分析起來(lái)還是有方法的。最好的防范就是使用strace去跟蹤df命令的堆棧?？纯磆ang在什么地方，就比較容易定位問(wèn)題了。

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