问题出现
有两台物理机，一台是192.168.1.15，另一台是192.168.1.43。二者的netsnmp版本相同。
使用snmpwalk去访问两台机器，获取tcp重传数(tcpRetransSegs)时，192.168.1.43回复时间非常长。多达140s+，但是相同配置的192.168.1.15只需要30ms。
-bash-4.1# time snmpwalk -v 2C -c cluster -t 200 -r 0 192.168.1.15 .1.3.6.1.2.1.6.12
TCP-MIB::tcpRetransSegs.0 = Counter32: 2364728
real 0m0.030s
user 0m0.020s
sys 0m0.003s
-bash-4.1# time snmpwalk -v 2C -c cluster -t 200 -r 0 192.168.1.43 .1.3.6.1.2.1.6.12
TCP-MIB::tcpRetransSegs.0 = Counter32: 3771986491
real 2m27.554s
user 0m0.020s
sys 0m0.003s
这个现象非常奇怪，按理说tcpRetransSegs是从/proc/net/snmp中直接拿数据然后解析，耗时应该非常短。不应该到秒级。
而且在使用time snmpwalk -v 2C -c cluster -t 200 -r 0 192.168.1.43 .1.3.6.1.2.1.6.12进行访问时，是立即返回了TCP-MIB::tcpRetransSegs.0 = Counter32: 3771986491的信息，但是接着卡住长达140s+，然后该命令才结束。
说明返回tcpRetransSegs的数据并没有消耗多少时间，但是之后未知的流程导致了巨大时间的消耗。
问题分析
对比了两台机器，发现二者最大的区别在于192.168.1.15上有较少的连接数，大概10+。而192.168.1.43上有多达4000+的连接数。
尝试只用snmpget来获取192.168.1.43上tcpRetransSegs的值
-bash-4.1# time snmpget -v 2C -c cluster -t 200 -r 0 192.168.1.43 .1.3.6.1.2.1.6.12.0
TCP-MIB::tcpRetransSegs.0 = Counter32: 3850778646
real 0m0.025s
user 0m0.023s
sys 0m0.002s
可以发现立即返回，而使用snmpwalk依然耗时巨大。
snmpwalk
snmpwalk是遍历mib上的某棵子树，包含了至少两个动作，get和getnext。
首先对于oid进行get操作，然后进行getnext，获取返回值和名称(oid)。 然后判断该返回的oid是否还在这个子树上，如果不在了，那么就结束。 如果还在该子树上，则使用返回的oid继续getnext，直到结束。
具体来说，就是time snmpwalk -v 2C -c cluster -t 200 -r 0 192.168.1.43 .1.3.6.1.2.1.6.12命令可以分为以下几部分：
首先对oid.1.3.6.1.2.1.6.12进行get。
-bash-4.1# time snmpget -v 2C -c cluster -t 200 -r 0 192.168.1.43 .1.3.6.1.2.1.6.12
TCP-MIB::tcpRetransSegs = No Such Instance currently exists at this OID
real 0m0.025s
user 0m0.019s
sys 0m0.001s
然后进行getnext
-bash-4.1# time snmpgetnext -v 2C -c cluster -t 200 -r 0 192.168.1.43 .1.3.6.1.2.1.6.12
TCP-MIB::tcpRetransSegs.0 = Counter32: 3815361069
real 0m0.025s
user 0m0.022s
sys 0m0.001s
因为返回的tcpRetransSegs.0在.1.3.6.1.2.1.6.12树上，因此继续getnext
-bash-4.1# time snmpgetnext -v 2C -c cluster -t 200 -r 0 192.168.1.43 .1.3.6.1.2.1.6.12.0
TCP-MIB::tcpConnState.0.0.0.0.22.0.0.0.0.0 = INTEGER: listen(2)
real 2m20.125s
user 0m0.022s
sys 0m0.002s
这次返回的tcpConnState.0.0.0.0.22.0.0.0.0.0已经出了.1.3.6.1.2.1.6.12树，因此snmpwalk结束。
这里也可以看到主要的耗时就是在这一步上了。而这一步耗时的主要原因是获取tcpConnState需要将所有的连接遍历一遍。
这也与观察到的192.168.1.43上连接数高相吻合。
结论
time snmpwalk -v 2C -c cluster -t 200 -r 0 192.168.1.43 .1.3.6.1.2.1.6.12耗时巨大的主要原因是错用了snmpwalk。导致去获取tcpConnState的数据，从而致使snmpd在分析所有的连接时，耗费了巨大的时间和CPU资源。
正确的方法应该是使用snmpget -v 2C -c cluster -t 200 -r 0 192.168.1.43 .1.3.6.1.2.1.6.12.0去获取数据。
这里也有一个教训，就是如果能够准确回去的oid数据，最好使用get，使用getnext会降低其效率。
出处：xinkun的博客
链接：https://xuxinkun.github.io/
本文版权归作者所有，欢迎转载。
未经作者同意必须保留此段声明，且在文章页面明显位置给出原文连接，否则保留追究法律责任的权利。
欢迎扫描右侧二维码关注微信公众号xinkun的博客进行订阅。也可以通过微信公众号留言同作者进行交流。
