We have a host about 320ms from our observium node (yes.. The other side of the planet).
Doing a full poll circa 650-700ms (including mac and bgp tables... Its a IOS-XR ASR9K ..). Adjusting the Cr/max-reps did increase speeds, and caused several nasty snmpd explosions on the chassis.
As a exercise in interest I spun up a VM much closer to the host, unpacked /opt/observium/mibs etc and configured snmp on that remote host.
Then did this
root@obs1:/opt/observium# diff -c includes/snmp.inc.php.orig includes/snmp.inc.php *** includes/snmp.inc.php.orig 2014-07-23 17:43:53.720274321 +0930 --- includes/snmp.inc.php 2014-07-23 17:56:23.092286235 +0930 *************** *** 333,338 **** --- 333,345 ---- // Add the OID(s) to the strong $cmd .= " ".$oids;
+ if( $device['hostname'] == 'faraway.router.com' ){ + $cmd = "ssh -i ~x/x.pem x@remote-poller-node -C " . escapeshellarg($cmd) ;
+ }
This was interesting, but the ssh establishment phase for each snmp execution was a lot of overhead.. So I also did this
root@obs1:/opt/observium# cat ~/.ssh/config
Host remote-poller-node # HostName machine1.example.org ControlPath ~/.ssh/controlmasters/%r@%h:%p ControlMaster auto ControlPersist 10m
This means that a ssh 'master instance' was setup at the start of the poll, and hangs around in the background between executions of various snmpcmd's during the poll.
Full poll went from 650-700ms -> ~170ms
Thought this might be of interest to some people.
Cheers, Peter