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


Planning Large Installations of PRTG Network Monitor

Votes:

0

Your Vote:

Up

Down

What do I have to take into account when planning a large installation of PRTG Network Monitor?

install installation large planning prtg siteplanner

Created on Oct 13, 2011 10:21:36 AM by  Daniel Zobel [Paessler Support]

Last change on Oct 13, 2011 10:36:11 AM by  Daniel Zobel [Paessler Support]



9 Replies

Accepted Answer

Votes:

2

Your Vote:

Up

Down

Planning Large Installations of PRTG Network Monitor

The maximum number of sensors you can monitor with one installation of PRTG mainly depends on the monitoring technology and the monitoring intervals you use. Please see also our system requirements that highlight recommended sensor counts for an ideal PRTG setup.

  • SNMP V1/V2, PING, PORT, and HTTP are the recommended sensor types for scenarios with thousands of sensors.
  • For SNMP V3 PRTG is able to handle roughly 40 requests per second and computer core, depending on your system. This means that, on a common 1.x GHz computer with two cores, you can run about 5,000 SNMP v3 sensors with a 60 seconds scanning interval; on a system with four cores, you can monitor around 10,000 sensors with 60 seconds interval. The CPU load is at about 50% then. We do not recommend more.
  • For WMI monitoring try to keep the number of WMI sensors per probe below 120 sensors (with 60s interval) or 600 sensors (with 300s interval).
  • For NetFlow (or sFlow, jFlow) monitoring the maximum number of sensors depends on the traffic pattern, the number of Flow packets per second received by the PRTG Probe, as well as the performance of the probe system.
  • Packet Sniffing creates the highest CPU load on the probe system. This technology is only recommended for monitoring of low traffic connections (<50 Mbit/s steady stream). When traffic is often over 10 Mbit/s a dedicated remote probe should be used.
  • For best performance of VMware sensors, we strongly recommend Windows Server 2012 R2 on the computer running the PRTG probe with the VMware sensors. On this operating system, you can monitor up to 300 VMware sensors in a 60 seconds scanning interval. Please see this article for details.

To overcome any limitations mentioned above you should distribute the sensors over two remote probes or more.

As a rule of thumb you should not experience any performance issues for installations when you stay under 2,000 sensors, under 30 remote probes, and under 30 user accounts. If the installation is planned well, PRTG can scale much higher.

For high-speed operation of the web interface (page times below 500ms) we recommend to stay below 5,000 sensors per installation. For clusters we recommend to stay below 2,500 sensors per cluster. If you plan an installation that monitors more than 5,000 sensors from one instance of PRTG on a physical device or more than 5,000 sensors with PRTG running on a virtual machine, we ask you to contact our pre-sales team for consultation. They will advise you on sensor limits and scanning intervals.

For more information, please see also PRTG Manual: Detailed System Requirements

See Also

Created on Oct 13, 2011 10:35:23 AM by  Daniel Zobel [Paessler Support]

Last change on Jan 11, 2017 1:36:22 PM by  Martina Wittmann [Paessler Support]



Votes:

0

Your Vote:

Up

Down

I'd like to add to this comment that it is possible to use more than 120 sensors for WMI. I think our current setup is approximately running a total of 1200 sensors (60 sec interval) with about 250 wmi sensors and we will be adding more of them.

We are however running this single server install on a dual xeon x5660 @ 2.6ghz 12 GB ram machine with a 1gb FBWC raid controler.

In this setup I have 24 cpu's according to task manager. CPU usage is light as well as memory usage.

I don't have jFlow working yet (due to a limitation on the SRX 240 not being able to send out jFlow on reth interfaces) so my main sensors are ping, snmp (v2) and WMI.

This is all local Lan so al latencies are <10ms and I have not had any performance issues. the troubles I've had with WMI are usually due to the fact that we have a lot of win2k8 (non r2) servers which pretty much hate WMI altogether.

Created on Oct 13, 2011 2:52:30 PM by  Megamuch (60) 1 1

Last change on Oct 13, 2011 3:05:02 PM by  Daniel Zobel [Paessler Support]



Votes:

0

Your Vote:

Up

Down

Well... it is actually possible to run 60K sensors on single core server install. In our install: 54K of them are snmp traffic sensors, 2k pings and the rest are mostly WMI, distributed across multiple probes. Server config: Cisco UCSC-C220-M3S, 2x E5-2690 v2@3GHz, 64GB RAM, 10K disks in RAID10, windows server 2012 R2 dtc. This includes hyper-v role, and 2 2k12r2 VM's, where most loaded probes are hosted. Problems: very large config file, around 4gb. Slow to apply config changes. I hope Paessler will do something about the way prtg stores config, so we can add even more sensors :)

Created on May 14, 2014 8:33:18 AM by  qurvax (40) 2



Votes:

0

Your Vote:

Up

Down

Well, qurvax, that's an impressive installation!

Created on May 20, 2014 4:30:52 PM by  Dirk Paessler [CEO Paessler AG]



Votes:

0

Your Vote:

Up

Down

Hi qurvax,

Thank you for sharing the information. Well , I am currently trying to convince my team to move away from cron based mrtg to PRTG , if we do I will be putting in approximately 2,74,280 snmp sensors. I am planning to spread them over probes ( May be 15+ ) , Would you recommend such large installation ?

Regards

Created on Nov 26, 2014 9:01:01 AM by  amarc (0) 1



Votes:

0

Your Vote:

Up

Down

If you are planning to use more than 250,000 sensors, I'd recommend to split the load to several core servers and use the Enterprise Console to administer each server. This will keep your installation healthy.

Created on Nov 27, 2014 2:39:01 PM by  Felix Saure [Paessler Support]



Votes:

0

Your Vote:

Up

Down

For some type of PRTG Sensors is recommended that we use not more than 50 (for WBEM or SOAP) or 200 (for WMI) sensors on each probe. Does it mean that we should use for example only 50 WBEM sensors on a probe with no other type of sensor or you Considered having other types beside this 50 sensors? Is it possible to have 50 SOAP Sensors+120 WMI Sensors+40 WBEM Sensors all together on a probe?What does it mean?

Created on May 9, 2015 4:19:27 AM by  AJamshidi (0) 1



Votes:

0

Your Vote:

Up

Down

I have to agree with Qurvax, please get rid of the flat xml config file. It seems to be the only thing that's slows us down is any config changes because of the file size. We have 20k sensors and a 1gb config file. Configuration changes are slow. If your not modifying any configurations the server seems to be fairly fast.

Created on Jul 2, 2015 10:24:56 PM by  tom234679 (250) 1



Votes:

0

Your Vote:

Up

Down

@AJamshidi: on Recommended number of Sensors per Probe

Generally spoken the recommendations that you find for each Sensor Type only apply to this Type, that means you can combine several Sensors and use those recommendations. Of course, you will also run into performance issues when you start exhausting those limits for alot of Sensors on a Probe, hence always try to balance the whole setup on a Probe, in order to keep a good performance.

Created on Jul 3, 2015 9:02:10 AM by  Andreas Heidrich [Paessler 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.