PRTG Manual: Detailed System Requirements

IMPORTANT INFORMATION
This section was moved and is no longer up to date. To get a comprehensive overview about basic and detailed system requirements, use section System Requirements.

There are different aspects that you need to consider regarding the system requirements for PRTG. Meet these requirements to avoid issues while you monitor your network.

In this section:

PRTG Hosted Monitor does not require any hardware for the PRTG core server, but it needs at least one remote probe installation to monitor your local network.

Supported Operating Systems for the PRTG Core Server and Remote Probes

Category	Requirements
Supported operating systems	The 32-bit and 64-bit versions of the following operating systems are officially supported for the PRTG core server service and PRTG probe service: Microsoft Windows Server 2019* Microsoft Windows Server 2016* Microsoft Windows Server 2012 R2* Microsoft Windows Server 2012* Microsoft Windows 10 Microsoft Windows 8.1 Microsoft Windows 8 Microsoft Windows 7 Microsoft Windows Server 2008 R2* * Windows servers in Core mode or Minimal Server Interface are not officially supported.
Operating system version	The version (32-bit or 64-bit) of the PRTG core server depends on the version of your operating system. The 64-bit version of the PRTG core server is installed if the operating system is a 64-bit Windows system, and the system provides 6 GB RAM or more. Otherwise, the 32-bit version of the PRTG core server is installed.
Microsoft .NET Framework	Microsoft .NET Framework .NET 4.7.2 or later must be installed on the PRTG core server system or the remote probe system. For new installations of the PRTG core server or remote probes, we recommend .NET Framework 4.8. For more information, see the Knowledge Base: Which .NET version does PRTG require? The .NET framework is imperative if you want to monitor VMware and XenServer virtual environments. Many other sensors also need an installed Microsoft .NET Framework.
Disabled FIPS mode	Make sure that the Federal Information Processing Standards (FIPS) mode (Windows security option "System Cryptography: Use FIPS-compliant algorithms for encryption, hashing, and signing.") is disabled on Windows systems that run the PRTG core server service or PRTG probe service. FIPS-compliant encryption can cause issues with sensors that use the .NET framework. For more information, see the Knowledge Base: Why should I disable the FIPS mode under Windows?

PRTG Hosted Monitor is restricted to a maximum of 10,000 sensors. More sensors are not possible.

Hardware and Network Size Requirements for the PRTG Core Server

Hardware requirements for the PRTG core server service mainly depend on the sensors and scanning intervals that you use. Your network size can also influence the performance of your monitoring.

Sensors per PRTG core server	CPU cores	RAM	Disk space	Concurrently active administrator sessions	Number of remote probes
Up to 500	4	4 GB	100 GB	< 30	< 30
Up to 1,000	6	6 GB	500 GB	< 30	< 30
Up to 2,500	8	8 GB	750 GB	< 20	< 60
Up to 5,000	8	12 GB	1,000 GB	< 20	< 60
Up to 10,000	10 - 12	16 GB	1,500 GB	< 15	< 80
> 10,000	We recommend that you set up additional PRTG core servers. For more information on scaling, you can also contact the Paessler Presales team.

Hardware and Network Size Requirements for Remote Probes

Hardware requirements for the PRTG probe service mainly depend on the sensors and scanning intervals that you use. Your network size can also influence performance of your monitoring.

Sensors per remote probe	CPU cores	RAM	Disk space
Up to 200	2	2 GB	40 GB
200 - 2,000	4	4 GB	40 GB
2,000 - 5,000	6	6 GB	40 GB
> 5,000	We recommend that you set up additional remote probes. For more information on scaling, you can also contact the Paessler Presales team.

A remote probe system does not have any special disk requirements (< 1 GB). In general, we recommend at least 40 GB.

General Performance Impact Considerations

Category	Performance Impact Considerations
Hardware resources	For a PRTG core server to work properly, it is crucial to have a certain amount of hardware resources available. If the server runs out of resources, PRTG sends warning and emergency messages to the primary email address of the PRTG System Administrator user. You receive warning messages if the available disk space falls below 1 GB or if the available memory falls below 500 MB, and emergency messages if the available disk space or memory fall below 50 MB. In this case, react immediately and free up system resources.
Sensors	Ping and SNMP sensors create much less load than complex sensors like xFlow sensors, VMware sensors, Sensor Factory sensors, WMI sensors. or Syslog Receiver or SNMP Trap Receiver sensors, for example. There are also limitations for some sensors that do not depend on hardware resources, for example, WMI and SNMP v3 sensors. You can overcome these limitations if you distribute the sensors between remote probes. For clusters, we recommend that you stay below 2,500 sensors per cluster.
Channels	We recommend that you use sensors with less than 50 channels. Note that sensors with more than 50 channels are not officially supported and can have a high impact on system performance.
Scanning interval	For a single PRTG core server setup without a cluster, we recommend that you mainly use 1-minute scanning intervals for up to 2,000 sensors and 5-minute intervals if you have more sensors. To give you an impression: To monitor 5,000 sensors with a 1-minute scanning interval, PRTG takes 7.2 million measurements and evaluates, notifies, and stores them. This adds 700 MB of additional data to the database every single day.
CPU-intensive features	Try to limit the use of the following features: Many quickly refreshed maps, The frequent generation of huge reports, Heavy usage of packet sniffing, Sensor Factory sensors, and Toplists, Frequent automatically scheduled auto-discoveries for large network segments, and Constant queries of monitoring data via the PRTG API.
Network connection quality	The quality of your network also plays an important role. When you monitor via User Datagram Protocol (UDP), for example, a high packet loss rate can lead to frequent timeouts. Remote probes that connect via unstable (WAN) connections can lead to delays as well.

Performance Impact Considerations Based on Sensor Types

You can find the performance impact of a specific sensor on the sensor's Overview tab or in the Add Sensor dialog.

For an overview list of sensors, including their performance impact, see section List of Available Sensor Types.

In general, consider the following rules for the of different sensor types:

Sensor Type	Performance Impact Considerations
SNMP v1 and v2, Ping, Port, and HTTP	We recommend that you use these sensor types for scenarios with thousands of sensors.
SNMP v3	SNMP v3 has performance limitations because of the use of encryption. The main limiting factor is CPU power. Furthermore, keep in mind that SNMP v3, unlike SNMP v1 and v2c, does not scale with more CPU power. Because of this limitation, you can monitor only a limited number of sensors per second using SNMP v3.
WMI	Try to keep the number of WMI sensors per probe below 120 sensors (with a 60-second scanning interval), or below 600 sensors (with a 300-second scanning interval).
xFlow	The maximum number of xFlow sensors depends on the traffic pattern, the number of xFlow packets per second that the probe receives, as well as the performance of the probe system.
Packet Sniffer	This sensor type creates the highest CPU load on the probe system. We only recommend this technology for monitoring low traffic connections (< 50 Mbit/s steady stream). If the traffic often exceeds 10 Mbit/s, use a dedicated remote probe.
VMware monitoring	Monitoring VMware is limited to about 30 sensors at a 60-second scanning interval, or 100 sensors at a 5-minute scanning interval. On probes that run on Windows Server 2012 R2 or later, you can use more VMware sensors. These limitations issue from the VMware platform. For more information, see the Knowledge Base: How can I increase the connection limit on VMware systems? PE121

You can overcome these limitations if you distribute the sensors between remote probes.

Running PRTG in Virtual Environments

You can run the PRTG core server and remote probes on virtualized platforms. However, PRTG consists of a lot of different components that all rely on the performance and the stability of the probe system where virtual environments add even more layers of complexity. This needs to be considered when you want to set up your PRTG installation in a way that you can achieve the same level of performance as on a physical server.

Most PRTG installations from 500 to 5,000 sensors do not need any specific optimization regarding your virtual infrastructure.

If you run larger installations of PRTG with more than 5,000 sensors, we strongly recommend that you follow the instructions in our Best Practice Guide: Running large installations of PRTG in a virtual environment.

Particularly for virtual systems, make sure that you have a unique Windows security identifier per system.

Running PRTG in a Cluster

We recommend a single failover cluster for fail-safe monitoring. This consists of two PRTG core servers that each work as a cluster node.

In a cluster, the monitoring load doubles with each cluster node, so the performance of each additional cluster node is halved. Therefore, in a single failover cluster, divide our recommended numbers from earlier in the section in half.

This feature is not available in PRTG Hosted Monitor.

Supported Web Browsers

Category	Requirements
Supported browsers	The following browsers are officially supported by the PRTG web interface (in order of performance and reliability): Google Chrome 72 Mozilla Firefox 65 Microsoft Internet Explorer 11 For security and performance reasons, we strongly recommend that you always use the latest version of Google Chrome to access the PRTG web interface.
Firefox	Firefox is potentially vulnerable to cross-site scripting (XSS) attacks. These XSS exploits are possible if you click, for example, phishing links in emails that contain malicious code, and you are logged in to PRTG with Firefox. For more information, see the Knowledge Base: How secure is it to access the PRTG web interface with Firefox?
Microsoft Internet Explorer 11 and unsupported browsers	Microsoft Internet Explorer 11 and older versions of Microsoft Edge, as well as other browsers that are not officially supported, have issues with some functionalities of the PRTG web interface. However, you can access the PRTG web interface with any browser. Deprecated Internet Explorer versions as well as some mobile browsers might not be able to display all features of the PRTG web interface.
Plugins	Plugins can also have an effect when you view the PRTG web interface. Make sure that you add exceptions for PRTG in the plugins' settings, particularly if you use ad blockers. For more information, see the Knowledge Base: The logs page in the PRTG web interface does not load. What can I do?

Screen Resolution

A screen resolution of at least 1024x768 pixels is sufficient for most functions of PRTG. However, we recommend a screen resolution of 1200x800 pixels or higher.

Requirements for Monitored Devices

Category	Requirement
SNMP monitoring	The monitored devices must support SNMP v1, v2c, or v3. An SNMP-compatible software must be installed on the device. You must enable SNMP on the device and you must grant the PRTG core server system access to the SNMP interface. For more information, see section Monitoring via SNMP.
Windows/WMI monitoring	To monitor via WMI, you need a Windows network. Use only the officially supported operating systems except for Microsoft Windows Server 2008 that has strong performance issues when you monitor via WMI. For more information, see section Monitoring via WMI.
xFlow monitoring	The monitored devices must be able to send NetFlow (NetFlow v5, NetFlow v9, or IPFIX) data packets or sFlow v5 packets to the probe system. For more information, see section Monitoring Bandwidth via xFlows.
Packet sniffer monitoring	PRTG can only analyze data packets that pass the local machine's network card. Switches with monitoring ports are necessary for network-wide monitoring in switched networks. For more information, see section Monitoring Bandwidth via Packet Sniffing.
Other sensor types	You can find specific sensor and device requirements (for example, modules, components, device configurations) in the corresponding sensor section and in the Add Sensor dialog.