SNMP troubles after 5R1.0 upgrade

[dlukinski]

After few week of usage I noticed that snmpwalk via GUI (apache) works from time to time even with 60-70 hosts (by now in our development) under monitoring.
Or it fails on the first attempt ("Next" to the 2nd scree), but works after "Back" and "Next" done once again.

Clearly something is not ideal, nor it is completely broken. Might be attributed to our highly virtualized environment.
Hope to see this addressed in future patches.

[ssax]

I've reached out to the developer who wrote that functionality, we'll see what he says.

60-70 hosts is a fairly small environment (depending on the number of service checks) so it shouldn't really affect that wizard.

What does your load look like?

Code: Select all

uptime
top

[ssax]

Also, edit your /etc/php.ini and increase your memory_limit:

Code: Select all

memory_limit = 256M

Then restart HTTPD and try it again:

Code: Select all

service httpd restart

[dlukinski]

I've reached out to the developer who wrote that functionality, we'll see what he says.

60-70 hosts is a fairly small environment (depending on the number of service checks) so it shouldn't really affect that wizard.

What does your load look like?

Code: Select all

uptime
top

[ssax]

Did you adjust the php memory_limit from the post after?

[dlukinski]

Did you adjust the php memory_limit from the post after?

Yes I doubled it (and could probably quadruple later on if required)
- please let me run snmpwalks for a week and let you know if there was a definite improvement

[hsmith]

Let us know.

Thanks!

[dlukinski]

Let us know.

Thanks!

For very remote snmpwalks this still fails, but for local ones things work
I wonder if this has to be doubled again (?)

[ssax]

What is the output of these commands:

Code: Select all

snmpwalk -v 2c -c COMMUNITY X.X.X.X:161 .1.3.6.1.2.1.25.2.3.1.3
snmpwalk -v 2c -c COMMUNITY X.X.X.X:161 .1.3.6.1.4.1.77.1.2.3.1.1
snmpwalk -v 2c -c COMMUNITY X.X.X.X:161 .1.3.6.1.2.1.25.4.2.1.2

Try running them multiple times to see if it fails as well.

Now let's check the size:

Code: Select all

snmpwalk -v 2c -c COMMUNITY X.X.X.X:161 .1.3.6.1.2.1.25.2.3.1.3 > /tmp/snmp_output_1.txt
snmpwalk -v 2c -c COMMUNITY X.X.X.X:161 .1.3.6.1.4.1.77.1.2.3.1.1 > /tmp/snmp_output_2.txt
snmpwalk -v 2c -c COMMUNITY X.X.X.X:161 .1.3.6.1.2.1.25.4.2.1.2 /tmp/snmp_output_3.txt
ls -l /tmp/snmp_output*

[dlukinski]

What is the output of these commands:

Code: Select all

snmpwalk -v 2c -c COMMUNITY X.X.X.X:161 .1.3.6.1.2.1.25.2.3.1.3
snmpwalk -v 2c -c COMMUNITY X.X.X.X:161 .1.3.6.1.4.1.77.1.2.3.1.1
snmpwalk -v 2c -c COMMUNITY X.X.X.X:161 .1.3.6.1.2.1.25.4.2.1.2

- did not fail against two very remote SNMPWALKs (except that 2nd command returns no object)



Try running them multiple times to see if it fails as well.

Now let's check the size:

Code: Select all

snmpwalk -v 2c -c COMMUNITY X.X.X.X:161 .1.3.6.1.2.1.25.2.3.1.3 > /tmp/snmp_output_1.txt
snmpwalk -v 2c -c COMMUNITY X.X.X.X:161 .1.3.6.1.4.1.77.1.2.3.1.1 > /tmp/snmp_output_2.txt
snmpwalk -v 2c -c COMMUNITY X.X.X.X:161 .1.3.6.1.2.1.25.4.2.1.2 /tmp/snmp_output_3.txt
ls -l /tmp/snmp_output*

[root@fikc-nagxiprod01 ~]# ls -l /tmp/snmp_output*
-rw-r--r-- 1 root root 875 Nov 11 17:10 /tmp/snmp_output_1.txt
-rw-r--r-- 1 root root 90 Nov 11 17:11 /tmp/snmp_output_2.txt
[root@fikc-nagxiprod01 ~]#

#3 not created.