Sensors crashing probe

With the scanning interval at 5 minutes the "Interval Delay non-WMI&SNMP" and "Interval Delay SNMP" went down to 0% but the "Open Requests" is still hanging around the 360 mark.

I have figured out for the most part the reason why my SNMP sensors aren't responding is because the ACL on each device is blocking them from being monitored by anything other than the core server. I have just scripted in a change for the ACLs.

Once the SNMP sensors are responding should the open requests go down?

Should it be ok to use a 60 second scanning interval?

Dear Matthew,

In general, we recommend to keep the amount of sensors per probe device below 2,500. "For SNMP V3 PRTG is able to ... on a system with four cores, you can monitor around 10,000 sensors with 60 seconds interval."

Per System, you can run up to 10,000 sensors, but per probe device up to 2,500 only (based on our recommendations) .

With the increased scanning interval, PRTG is able to distribute the scans over a larger time period which reduces the load and the delay fall/disappear. However, the probe has still too many sensor scans in its queue, which is the reason for the persistent number of open requests.

So, please add additional Remote Probe devices to your system and distribute your sensors to these additional probe devices.

Once you have done this, the amount of open requests should fall significantly.

Best regards,
Sven

Hi Sven, Up until the weekend I had all of these sensors on the local probe associated with my core installation. The local probe health sensor showed the following averaged for one day:

• Open Requests = 121
• Probe Process CPU Load = 10%
• Interval Delay WMI = 0% Delay
• Interval Delay SNMP = 0% Delay
• Interval Delay non-WMI&SNMP = 0% Delay
• Memory Usage = 913 MByte

I expected a similar result when I moved all of the devices to the remote probe. Any thoughts as to why I was wrong?

Dear Matthew,

The most likely reason why you didn't see the same results on the Remote Probe device due to some missing firewall rules or to routing issues, or because the devices which send SNMP data has configured the Local Probe device as a receiver only. That's why the requests couldn't be finished which increased the amount of open requests and delays as well.

Nevertheless, while the delays in the above statistics look very good, the amount of open requests is still higher than recommended. So, I advice you to distribute your sensors over Local and Remote Probe in order to split the monitoring load over both probe devices.

Once you have done this, you might need to adjust your firewall/routing rules and/or adjust the receiver IP in the SNMP data sending devices as well.

Best regards,
Sven

Hi Sven,

That makes a lot of sense. Hopefully once our ACLs are changed and the routers start responding the open requests will drop.

The other thing that is different is the amount of cores on the core server vs the amount of cores on the remote probe.

How does the amount of cores/number of processors effect a PRTG probe?

Will upgrading the CPU help lower the amount of open requests?

Thanks,

Matthew

Dear Matthew,

In general, we recommend to use 1 Core and 1-2 GB of RAM per 1,000 sensors as you can see in our detailed system requirements. However, at a certain point, throwing more hardware on the system does not help anymore.

If you run too many and/or to heavy sensors, adjusting the intervals and distributing the sensors over several probe devices is the only thing which helps in order to obtain best performance and stability.

Please refer to the links below for some further hints:

• How can I speed up PRTG—especially for large installations?
• I run PRTG on VMware. How can I obtain best performance?

Best regards,
Sven