What do I have to take into account when planning a large installation of PRTG Network Monitor?
This article applies to PRTG Network Monitor 19 or later
Planning Large Installations of PRTG Network Monitor
The maximum number of sensors that you can monitor with one installation of PRTG mainly depends on the monitoring technology and the monitoring intervals you use. 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 per 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-second scanning interval; on a system with four cores, you can monitor around 10,000 sensors with a 60-second 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 a 60-second interval) or 600 sensors (with a 300-second 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 low traffic connections (<50 Mbit/s steady stream). If traffic often goes beyond 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 that is running the PRTG probe with the VMware sensors. On this operating system, you can monitor up to 300 VMware sensors within a 60-second scanning interval. See the article How can I increase the connection limit on VMware systems? 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 with installations if you stay under 5,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 that you stay below 5,000 sensors per installation. For clusters we recommend that you 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.
Performance can also vary depending on the number of channels per sensor. Note that sensors with more than 50 channels are not officially supported and can have a high impact on system performance.
For more information, see also PRTG Manual: Detailed System Requirements
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.
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 [email protected], 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 :)
Well, qurvax, that's an impressive installation!
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 ?
If you are planning to use more than 10,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.
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?
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.
@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.