I'm currently running on 1.2.14. I'm experiencing a problem with the 'SNMP Bulkwalk Fetch Size' parameter. Somehow this was set to 60. I had a device which could not run any data queries, and they would all produce this error:
ERROR: Data Query returned no indexes.
Through my debugging process I started looking at TCP traffic, and found these notable items:
00:47:25.417177 IP 1.1.1.70.48162 > 1.1.1.14.snmp: C=public GetBulk(32) N=0 M=60 .1.3.6.1.4.1.3854.3.5.3.1.1
00:47:26.028596 IP 1.1.1.14.snmp > 1.1.1.70.48162: C=public GetResponse(32) tooBig[errorIndex==0] .1.3.6.1.4.1.3854.3.5.3.1.1=
00:47:26.028850 IP 1.1.1.70.48162 > 1.1.1.14.snmp: C=public GetRequest(32) .1.3.6.1.4.1.3854.3.5.3.1.1
00:47:26.030905 IP 1.1.1.14.snmp > 1.1.1.70.48162: C=public GetResponse(32) noSuchName@1 .1.3.6.1.4.1.3854.3.5.3.1.1=
I realized the M=60 seemed like a query size, and that was actually what the 'Maximum OIDs Per Get Request' was set to for that device. So, I changed that to 10. But that didn't fix it. So, then I stumbled upon the global 'SNMP Bulkwalk Fetch Size' which was also set at 60. I tinkered with this and found that the maximum value I could use with this device was 30. But while I was troubleshooting this, I found that setting it to 30 yielded a 35 second runtime of the verbose data query. Setting it to 10 cut that query time in half, to just 16 seconds.
So, I don't really understand where the performance gains are with this setting. It seems to fetch the same information over and over again. My script query actually executed this GetBulk operaiton 19 times during a verbose query. Plus, there was no evidence of a problem in the logs, and the one error message I did get about having no indexes was very misleading. This "tooBig" response should likely be caught by Cacti somewhere and alerted on. Lastly, I'm not sure it's the best idea to have this defined as a global setting. It should likely be per-host, just like 'Maximum OIDs Per Get Request' is.
But, my problem is solved for now. I have my data query working. I am going to try and make a mental note not to ever increase this Bulkwalk Fetch Size.
I'm currently running on 1.2.14. I'm experiencing a problem with the 'SNMP Bulkwalk Fetch Size' parameter. Somehow this was set to 60. I had a device which could not run any data queries, and they would all produce this error:
Through my debugging process I started looking at TCP traffic, and found these notable items:
I realized the M=60 seemed like a query size, and that was actually what the 'Maximum OIDs Per Get Request' was set to for that device. So, I changed that to 10. But that didn't fix it. So, then I stumbled upon the global 'SNMP Bulkwalk Fetch Size' which was also set at 60. I tinkered with this and found that the maximum value I could use with this device was 30. But while I was troubleshooting this, I found that setting it to 30 yielded a 35 second runtime of the verbose data query. Setting it to 10 cut that query time in half, to just 16 seconds.
So, I don't really understand where the performance gains are with this setting. It seems to fetch the same information over and over again. My script query actually executed this GetBulk operaiton 19 times during a verbose query. Plus, there was no evidence of a problem in the logs, and the one error message I did get about having no indexes was very misleading. This "tooBig" response should likely be caught by Cacti somewhere and alerted on. Lastly, I'm not sure it's the best idea to have this defined as a global setting. It should likely be per-host, just like 'Maximum OIDs Per Get Request' is.
But, my problem is solved for now. I have my data query working. I am going to try and make a mental note not to ever increase this Bulkwalk Fetch Size.