I wonder if using a max number of gets would still increase performance over walking... :-)
On 9/10/2018 1:45 PM, Attila Nagy wrote:
Further info about this bug: From my testing it seems that using snmpget with lots of OID's makes the switch freeze. More exactly: using the command line as used by Observium (quoted in my original mail) has a limit of 24, so the 25th OID causes the switch to freeze, while 24 OID's produce consistent valid output. Interestingly, when used with the same OID (eg: ifOutOctets.1 ifOutOctets.1 ifOutOctets.1 ..., or ifMtu.1 ifMtu.1 ifMtu.1 .... etc.) then 12 is the magic limit number. Hmmm...
On 2018-09-10 10:49, Attila Nagy wrote:
Thanks Mike,
disabling separate_walk solved the issue for the test device. We are gonna go through all the sensitive switches and disable/test them one-by-one, and report back with the final outcome.
Is there anything we can do to further narrow down the problem?
As I mentioned we have a test hardware so we can run some tests (or we can even put it on-line if you want to get direct access to it).
Regards, Tylla
On 2018-09-07 23:53, Mike Stupalov wrote:
Hrm,
on all my tested TP-Link switches this feature improved polling speed. That why separate_walk feature for this os enabled.
But such problems are certainly unacceptable, I will disable that for os.
Anyway, if you have not so many devices, goto device edit page -> Modules -> disable 'separate_walk' option.
-- Mike Stupalov https://stupalov.com
-- Mike Stupalov Observium Limited, http://observium.org
observium mailing list observium@observium.org http://postman.memetic.org/cgi-bin/mailman/listinfo/observium
observium mailing list observium@observium.org http://postman.memetic.org/cgi-bin/mailman/listinfo/observium