背景

筆者負(fù)責(zé)維護(hù)的是net-snmp這份源代碼，原先的代碼在arp表項(xiàng)打滿的情況下會(huì)出現(xiàn)嚴(yán)重的性能問(wèn)題，原因在于使用鏈表來(lái)保存arp表項(xiàng)，而從/proc/net/arp文件中讀取出來(lái)的表項(xiàng)是無(wú)序的，但最終又要將數(shù)據(jù)按照ifindex和ip進(jìn)行排序，所以查找就十分的耗性能，筆者經(jīng)過(guò)一番分析之后，采用紅黑樹(shù)來(lái)保存arp表項(xiàng)，在初始化時(shí)使用netlink從內(nèi)核而不是/proc/net/arp文件把數(shù)據(jù)dump出來(lái)，紅黑樹(shù)的key使用ifindex與ip作為聯(lián)合key進(jìn)行排序，這樣查找的效率就會(huì)高很多，性能問(wèn)題也就因此而解決了，但是使用netlink會(huì)存在兩種出錯(cuò)的可能，第一種是內(nèi)存耗盡，第二種是用戶的接收緩沖區(qū)滿了，這時(shí)會(huì)返回ENOBUFS的錯(cuò)誤，筆者當(dāng)時(shí)對(duì)這種緩沖區(qū)滿的情況考慮不周，主要是不知道如何復(fù)現(xiàn)這種情況，就處理的比較粗糙，結(jié)果真的出現(xiàn)了這種問(wèn)題，特此記錄一下

重現(xiàn)步驟

使用工具打滿arp表項(xiàng)（16384條），禁用掉端口，導(dǎo)致arp瞬間失效，這時(shí)就會(huì)通知用戶進(jìn)程，因?yàn)橛脩暨M(jìn)程處理較慢，就會(huì)出現(xiàn)緩沖區(qū)滿的問(wèn)題

解決方案

當(dāng)出現(xiàn)用戶進(jìn)程數(shù)據(jù)與內(nèi)核數(shù)據(jù)不一致的情況時(shí)，清空用戶進(jìn)程的數(shù)據(jù)，重新加載內(nèi)核數(shù)據(jù)，保持一致性。