? ? ??

????昨天同事跟我說cacti突然抓不到一臺服務(wù)器的snmp數(shù)據(jù)了，讓我看看，然后就匆匆出去了。。登陸服務(wù)器后簡單查看了下161端口開著，進(jìn)程也沒什么可疑的，就重啟了snmpd服務(wù)，用

snmpwalk -v 2c -c public localhost .1.3.6.1.2.1.1.3

命令，發(fā)現(xiàn)已經(jīng)可以抓取到數(shù)據(jù)了，本以為問題已經(jīng)解決，誰知道剛過了10秒又出現(xiàn)同樣的故障了。。運行 netstat -an|grep -w “161”，發(fā)現(xiàn)Recv-Q的數(shù)據(jù)有些異常，正常情況應(yīng)該為0，現(xiàn)在卻是86533，說明數(shù)據(jù)已經(jīng)接收了，卻一直處在等待接受的緩沖區(qū)。。初步懷疑是不是受到***，因為我們公司使用的共同體是默認(rèn)的public，于是修改snmp的配置文件更改為pub，重啟服務(wù)后發(fā)現(xiàn)又正常了，netstat -an|grep -w “161”，Recv-Q的數(shù)據(jù)也重新變?yōu)?了，測試也并未出現(xiàn)異常了。。

????后來同事回來了，我問他做了什么修改，他說只是發(fā)現(xiàn)服務(wù)器上運行了并不需要的nfs服務(wù)，就把他停掉了。我把解決問題的過程告訴他，他說出現(xiàn)這個問題應(yīng)該跟外部的***無關(guān)，可能還是內(nèi)部的沖突引起的，于是我們又重新更改共同體為public，。發(fā)現(xiàn)問題又再次出現(xiàn)了。。。因為是停用nfs引起的故障所以肯定是跟nfs有關(guān)系，后來我們確認(rèn)不需要nfs服務(wù)，卸載nfs問題解決。。

? ? 上網(wǎng)查資料，發(fā)現(xiàn)問題可能是“網(wǎng)絡(luò)包分片導(dǎo)致的溢出”，以下是網(wǎng)上的資料寫的：

????當(dāng)rsize/wsize大于網(wǎng)絡(luò)的MTU（大部分網(wǎng)絡(luò)都是1500，除非設(shè)置了支持大包）時，IP包在用UDP協(xié)議傳輸時會分片。大量IP包分片會消耗網(wǎng)絡(luò)兩端大量的CPU資源，而且還會導(dǎo)致網(wǎng)絡(luò)通信更不穩(wěn)定（因為完整的RPC在UDP分片的任何一個包丟失時都得整個RPC重傳）。任何RPC的重傳增加都會導(dǎo)致時延的增加。這是NFS over UDP性能的最大瓶頸。

????如果你的網(wǎng)絡(luò)拓?fù)浜軓?fù)雜，UDP的分片包的路由很可能不同，可能不會都及時到達(dá)服務(wù)器。內(nèi)核對分片包的緩存有限制，最大值由ipfrag/_high_thresh指定。可以查看文件/proc/sys/net/ipv4/ipfrag_high_thresh和/proc/sys/net/ipv4/ipfrag_low_thresh。一旦未處理的包數(shù)目超過ipfrag_high_thresh，內(nèi)核就會丟棄分片包，直到數(shù)量達(dá)到ipfrag_low_thresh

????另一種監(jiān)視的方法是文件/proc/net/snmp中的IP：ReasmFails。這是分片組合失敗的數(shù)量，如果這個值在大量文件傳輸過程中上升太快，就有可能是有上述問題。

如果你在使用NFS客戶端，你可能會想要監(jiān)視IP重組失敗的數(shù)量（內(nèi)核重組包括網(wǎng)絡(luò)碎片數(shù)據(jù)的數(shù)據(jù)包失敗），可以通過SNMP變量IP-MIB::ipReasmFails實現(xiàn)，下面是一個簡單的命令：

#snmpwalk localhost -c public IP-MIB::ipReasmFails.0

? ?

????雖然最終問題解決了，但還有一個疑問就是為什么我更改了默認(rèn)的public之后就會正常呢，看來還要再查查資料了。

? ??

轉(zhuǎn)載于:https://blog.51cto.com/emile2016/1548156

總結(jié)

以上是生活随笔為你收集整理的停用nfs导致cacti无法抓取snmp数据的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。