New Question
 
 
PRTG Network Monitor

Intuitive to Use.
Easy to manage.

200.000 administrators have chosen PRTG to monitor their network. Find out how you can reduce cost, increase QoS and ease planning, as well.

Free PRTG
Download >>

 

What is this?

This knowledgebase contains questions and answers about PRTG Network Monitor and network monitoring in general. You are invited to get involved by asking and answering questions!

Learn more

 

Top Tags


View all Tags


Sensors crashing probe

Votes:

0

Your Vote:

Up

Down

In the thread below it says, "SNMP V1/V2, PING, PORT, and HTTP are the recommended sensor types for scenarios with thousands of sensors."

And, "For SNMP V3 PRTG is able to ... on a system with four cores, you can monitor around 10,000 sensors with 60 seconds interval."

I have just set up a probe on a dedicated machine with the following specs:

  • 4 Core Intel Xenon E5620 2.4GHz Processor
  • 4GB RAM
  • 1TB HDD

On the probe I have 9700 sensors which are only ping and SNMP v2 sensors with a 60 second scanning interval. My issue is that the probe health sensor is down and 1/3 of the sensors on the probe are down.

The message said that there was:

  • 700% Interval Delay non-WMI&SNMP
  • 480% Interval Delay SNMP
  • 499 Open Requests

My memory usage was 270MB and Probe Process CPU Load was around 18%

I left it like this over the weekend thinking that maybe the new probe needed time to catch up but there was no change when I came in this morning. I have just increased the scanning interval to 5 minutes to see what happens.

From what I've read the probe should be able to handle this load. Any ideas on what my be going wrong?

large-number-of-sensors open-requests probe

Created on May 14, 2018 8:39:57 AM by  Matthew Lawson (60) 2 1

Last change on May 15, 2018 6:01:11 AM by  Sven Roggenhofer [Paessler Technical Support]



6 Replies

Votes:

0

Your Vote:

Up

Down

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?

Created on May 14, 2018 9:56:28 AM by  Matthew Lawson (60) 2 1



Votes:

0

Your Vote:

Up

Down

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

Created on May 14, 2018 12:21:22 PM by  Sven Roggenhofer [Paessler Technical Support]



Votes:

0

Your Vote:

Up

Down

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?

Created on May 14, 2018 12:58:50 PM by  Matthew Lawson (60) 2 1



Votes:

0

Your Vote:

Up

Down

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

Created on May 15, 2018 6:33:57 AM by  Sven Roggenhofer [Paessler Technical Support]



Votes:

0

Your Vote:

Up

Down

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

Created on May 15, 2018 10:07:07 AM by  Matthew Lawson (60) 2 1



Votes:

0

Your Vote:

Up

Down

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:

Best regards,
Sven

Created on May 16, 2018 5:56:30 AM by  Sven Roggenhofer [Paessler Technical Support]



Please log in or register to enter your reply.


Disclaimer: The information in the Paessler Knowledge Base comes without warranty of any kind. Use at your own risk. Before applying any instructions please exercise proper system administrator housekeeping. You must make sure that a proper backup of all your data is available.