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

PRTG Network Monitor

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

Free Download

Top Tags


View all Tags

How can I speed up PRTG—especially for large installations?

Votes:

4

Your Vote:

Up

Down

With a few hundred sensors, PRTG usually does not show any speed and performance issues. But with thousands of sensors, you might experience excessive CPU load, a slow PRTG web interface, or sensors that are not scanned at the specified intervals.

What can I do to make PRTG faster, use fewer system resources, and work more reliably?

  • What aspects do I have to consider before the installation?
  • What are best practices for large installations of PRTG?
  • What can I do to enhance user experience, especially in the PRTG web interface?
  • What can I do to speed up my installation?

hardware important installation make-faster planning prtg sensor-type server-settings speed troubleshooting

Created on Mar 19, 2010 12:24:20 PM by  Daniel Zobel [Product Manager]

Last change on Mar 30, 2021 8:21:24 AM by  Maike Guba [Paessler Support]



15 Replies

Accepted Answer

Votes:

9

Your Vote:

Up

Down

This article applies as of PRTG 21

How to speed up PRTG

To speed up your PRTG core server system, consider the following topics:

  1. Hardware
  2. Operating system
  3. PRTG core server settings
  4. Sensor type and monitoring
  5. Housekeeping and maintenance
  6. More resources and facts

1. Hardware

Important: Choose performant hardware.

Physical and virtual servers

In general, we recommend that you use a dedicated physical machine to run both the PRTG core server and remote probes. The best configuration for running a PRTG core server is 2 sockets with multiple CPU cores. For remote probes, it is a single socket with multiple CPU cores.

If your PRTG core server or remote probe is running on a virtual machine (VM), make sure that you configure the VM with a multi-core-per-socket configuration. By default, your hypervisor might configure the VM the other way around (multiple virtual CPU sockets, each with one core).
In total, both approaches result in the same number of virtual CPU cores. However, the multi-core-per-socket configuration increases the CPU performance compared to the multi-socket single-core configuration, which might result in performance issues within the VM.

Running large installations of PRTG in a virtual environment is possible if you follow some specific rules and guidelines to achieve the required level of performance. For more information, see our Best Practice Guide: Running large installations of PRTG in a virtual environment.

Use multi-core, multi-threaded CPUs, and/or multi-processor systems

PRTG makes heavy use of multi-threading, so prefer systems with multiple cores. At least 4 cores are mandatory. In our tests, Intel processors outperformed AMD CPUs.

Install more RAM

More available memory can significantly improve the speed of PRTG.

  • 32-bit operating system: Install 4 GB of RAM. This maximizes the available RAM and disk cache.
  • 64-bit operating system: Install at least 4 GB of RAM. 8 GB is even better and for more than 2,500 sensors, we strongly recommend to install 8 GB of RAM.

Use a fast disk subsystem

  • Stick to simple RAID deployments like RAID 10 or RAID 1 for best performance with any controller or setup.
  • As a rule of thumb, higher RPM disks are always faster than lower RPM disks.
  • Avoid storage that adds a lot of overhead (iSCSI or SMB shared folder or drive) to disk access.
  • Use SSDs. Measurements show that using an SSD in a PRTG server can decrease page load times by 25-35% compared to a normal disk. Even faster are M.2 SSDs with NVMe.

More

For detailed figures of tests on different hardware platforms and operating systems, see section More Resources below.


2. Operating system

There are huge differences between the various Windows versions.

64-bit Windows version is better than 32-bit

According to our tests, 64-bit operating systems have a somewhat higher performance compared to 32-bit systems.

Select the fastest operating system available to you

The best operating systems for PRTG are, in order of performance:

  1. Windows Server 2012 R2
  2. Windows Server 2016 and Windows Server 2019
  3. Windows 10 and Windows 8.1
  4. Windows Server 2008 R2
  5. Windows 7

Avoid Windows Vista and Windows 2008 R1

Both Windows Vista and the first edition of Windows Server 2008 have serious performance issues, particularly if you use WMI. Do not use these operating systems for large installations.

Note: Windows Vista is not officially supported anymore. See Windows Vista support has ended for more information.

Avoid the Balanced power plan on Windows Server 2008

On Windows Server 2008, the power plan Balanced is the default setting. Switching to the High Performance power plan can lower your average web page load times by 30-50%, even if you use other Windows versions. Our observation is that the effect increases with multi-core CPUs.

See also: Why is the performance of my PRTG Core Server so low under Windows 2008?

More

For detailed figures of tests on different hardware platforms and operating systems, see section More Resources below.


3. PRTG core server settings

You can increase performance with a smart configuration of your PRTG core server.

Use the latest PRTG version

We continuously improve our software. To benefit from all speed enhancements, always run the latest PRTG version that is available for download. Use the auto-update functionality of PRTG to make sure that you always run the latest version.

Configure memory usage

Check the memory usage of your PRTG Server process. For values above 1 GB, navigate to Setup | System Administration | User Interface in the PRTG web interface, section Graph Settings, to reduce RAM usage. Choose the smallest settings that still make sense for your use case. The objective is to avoid slow memory swapping at all costs.

Note: In previous PRTG versions, define this setting in the PRTG Server Administrator tool, tab Memory usage.

Use the setting to limit features

This setting disables a few non-mission-critical features to speed up the PRTG web interface: Select Setup | System Administration | User Interface from the main menu. In the PRTG Web Server section, select Limit features and delay display under Performance Handling.

Switch the PRTG web server from HTTPS to HTTP

If you can afford a lower security level (for example, if your PRTG web server is not publicly accessible), you can disable HTTPS for the PRTG web server. If the internal web server is not encrypted, it delivers web pages faster and does not have to handle that much workload. Change this setting under Setup | System Administration | User Interface, section PRTG Web Server in the PRTG web interface.

Note: In previous PRTG versions, you can find this setting in the PRTG Server Administrator tool.

Test the speed of your browser

To test the speed of the PRTG web interface and measure the success of any optimization efforts, log in to the PRTG web interface and manually call the /speedtest.htm URL in your browser, for example http(s)://<your-prtg-ip-address-or-dns-name>/speedtest.htm


4. Sensor type and monitoring

A solid monitoring configuration can considerably improve performance.

Use longer scanning intervals

You can reduce monitoring load and data volume by 80% if you switch the scanning interval of all your sensors from 1-minute to 5-minute intervals. The best way to do this is to change the scanning interval in the root group settings and use the inheritance mechanism of PRTG to use this scanning interval for all objects that are underneath in the object hierarchy.

Avoid frequent auto-discoveries

Depending on your configuration, the auto-discovery can scan your entire network and therefore produce a certain amount of load. Minimize the number of scheduled auto-discoveries whenever possible. We recommend that you do not schedule an auto-discovery to run every hour. If possible, set the auto-discovery schedules to Once and run the auto-discovery manually when necessary.

Use multiple remote probes

Distributing the monitoring load among several remote probes is always a good idea to relieve your system.

Prefer basic sensor types

Basic sensors produce little header traffic or system load. They use fewer system resources than the more advanced technologies:

  • SNMP
  • PING
  • HTTP
  • SMTP
  • Port
  • DNS
  • FTP
  • POP3

Avoid a high number of channels per sensor

Avoid a high 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.

Use SNMP v2c and avoid SNMP v3

SNMP v3 does not scale well. SNMP v3 uses SSL encryption and creates a lot of CPU load. SNMP v1, on the other hand, does not support 64-bit counters. This can result in invalid traffic data.

Avoid WMI if possible

Avoid WMI because it does not scale well. WMI uses DCOM to connect to other systems and has several mutex/semaphore issues that affect scaling.

Avoid network-intensive and more complex sensor types

Keep the usage of sensors with a high or very high performance impact to a minimum. For more information, see the PRTG Manual: List of Sensors by Performance Impact.

Use NetFlow and sFlow instead of packet sniffing

For monitoring high-bandwidth networks, NetFlow and sFlow are far more efficient than packet sniffing. For more information, see the PRTG Manual: Bandwidth Monitoring Comparison.

Minimize the use of NetFlow and sFlow sensors

Depending on the traffic pattern, using NetFlow or sFlow can create a lot of CPU load and data.

Avoid Toplists

Keep the usage of Toplists to a minimum. Depending on the traffic pattern and Toplist configuration, this feature can create a lot of CPU load and data.

Avoid multiple user accounts and user groups

In large installations, multiple user accounts and user groups can slow down web server performance. In any case, stay below 20 user accounts for installations with more than 2,500 sensors.

Avoid defining many different access rights per object

In large installations, this could slow down the PRTG web server performance, depending on the depth of the object hierarchy in your device tree.

Avoid the use of dependencies

In large installations, avoid configuring many different dependencies. In normal installations, dependencies do usually not cause any issues.

Manage the use of schedules

Up to 20 schedules are no problem in any installation.

Manage the use of libraries

Remove all (default) libraries that you do not need.

Avoid huge reports

Reports can considerably slow down the system. Create only the smallest reports possible, avoid reports with many sensors over long periods, and run reports during times when nobody or few people use the PRTG web interface.

Turn off the Similar Sensors Detection feature

With the recommended default setting, PRTG automatically disables the similar sensors detection if your installation exceeds 1,000 sensors. If you want to keep the system load of PRTG to a minimum even for smaller installations, turn off the similar sensors detection completely.

Turn off the Recommended Sensors Detection feature

With the recommended default setting, PRTG automatically disables the detection engine if your installation exceeds 5,000 sensors. If you want to keep the system load of PRTG to a minimum even for smaller installations, turn off the recommended sensors detection completely.


5. Do regular cleanups

Keep an eye on your PRTG core server system and setup.

Restart regularly

We found that, in the long run, servers run more reliably when they are restarted once a month. Consider automatic restarts as often as once per week for systems that run heavily-used remote probes, too.

You can schedule an automatic remote probe restart in the probe settings in the PRTG web interface, section Administrative Probe Settings.

Note: In previous PRTG versions, set automatic Restart Options in the Probe Administrator tool, tab Start/Stop.

Regularly defragment hard disks drives (HDD)

PRTG constantly stores data and logfiles on the disk. For large installations, the constant flow of data to the disk can amount to many gigabytes per day. Although PRTG has built-in methods to minimize disk fragmentation, the data on your disk heavily fragments because many large files are simultaneously and incrementally stored throughout the day.

If you use HDDs, we recommend that you do a defragmentation once per day. This is not necessary if you use solid state drives (SSD).

Disable NTFS compression

By default, NTFS compression for the \Monitoring Database subfolder of the PRTG data directory is disabled as of PRTG 12. We found that disabling compression actually increases performance for small to medium installations because less data needs reading. This leads to less fragmentation. In large installations, this can have the opposite effect.

To disable compression in (deprecated) versions before PRTG 12, where it was automatically enabled during installation, open the PRTG Server Administrator tool, go to the Core Server tab and disable the check box next to Use NTFS based file compression.

If you have enabled NTFS compression in an older version and are now running PRTG 12 or later, see How can I disable/enable NTFS compression for PRTG's local data storage?.

Note: Do not convert already compressed data to uncompressed data. This process causes heavy fragmentation.


More

Created on Mar 19, 2010 1:40:54 PM by  Dirk Paessler [Founder Paessler AG] (10,972) 3 4

Last change on Sep 7, 2021 11:16:58 AM by  Maike Guba [Paessler Support]



Votes:

1

Your Vote:

Up

Down

Created on Apr 6, 2010 7:50:43 AM by  Jens Rupp [Paessler Support]

Last change on Apr 12, 2010 8:22:52 AM by  Daniel Zobel [Product Manager]



Votes:

0

Your Vote:

Up

Down

In your article above, you mentioned...

"Keep usage of the following sensors to a minimum: Sensor Factory, Packet Sniffers, VMware, Email Round Trip, SQL Server, Cloudwatch, QoS, File, Folder, HTTP Full Page, Custom EXE Sensors"

We have a fairly large installation of PRTG with over 7,000 sensors. We have quite a few of the above mentioned sensors. It would be helpful to have more solid guidelines on usage of these sensors rather than simply to keep them at a minimum. How many is too many? Can you give us a number or a percentage?

Created on Nov 1, 2010 2:50:34 PM by  Scott K (60) 1 1



Votes:

0

Your Vote:

Up

Down

@Scott K: The sensor types mentioned for "keep to a minimum" are either creating considerable more CPU or considerable more network load so we recommend to avoid using them too often (more than 10-100 sensors per type) in large installations.

On the other hand especially PING and SNMP sensors are creating the smallest footprint of all sensor types, followed by the Internet standard protocols like HTTP, SMTP, POP3, IMAP. WMI uses a lot more cpu cycles, etc.

What we want to say with "keep to a minimum": If you can perform monitoring for specific devices with the less cpu intensive sensors you should do so.

Note: Most of these considerations only come into perspective if you hit any resource limits in the first place.

Created on Nov 2, 2010 7:31:10 AM by  Dirk Paessler [Founder Paessler AG] (10,972) 3 4



Votes:

0

Your Vote:

Up

Down

Another solution for Defrag which is Free for Commercial use is Auslogics Disk Defrag (http://www.auslogics.com/en/software/disk-defrag/) which seems to be more powerfull and still developped.

Created on Mar 21, 2014 9:11:23 PM by  nolme (0) 1



Votes:

0

Your Vote:

Up

Down

Reading through this article it shows that 2008-R2 is preferred over 2012-R2. This article was last updated in 2011. Is this still the case ? I am upgrading my large installation to new hardware.

Created on Sep 17, 2014 10:30:44 AM by  Declan Costello (0) 1

Last change on Sep 18, 2014 11:59:40 AM by  Felix Saure [Paessler Support]



Votes:

0

Your Vote:

Up

Down

Hello Declan,

Our latest speed tests have shown that Windows Server 2008 R2 offers the best performance. Nevertheless many customers are using Windows Server 2012 R2 for large installations without performance issues. The best way to reduce the load on the core server is to distribute your sensors to multiple remote probes.

Best regards

Created on Sep 18, 2014 12:13:02 PM by  Felix Saure [Paessler Support]



Votes:

0

Your Vote:

Up

Down

Free Tip!

If you have installed PRTG on a vmWare Virtual Machine and if you are using HP ProLiant hardware, be sure the Power Profile is set to High Performance. It gives you a lot more performance! High vs dynamic power profile

Created on Oct 21, 2014 9:45:32 AM by  Martijn Goorman >> DataVisual (0)



Votes:

0

Your Vote:

Up

Down

I just pushed past 40,000 sensors on a Vmware VM with 12 CPU cores, 48GB of RAM and a 2TB drive for the database.

I have hit a wall with disk performance. My average queue length is between 4 and 5 and disk is busy 95% of time.

All my sensors are SNMP ( with a handful of exceptions ) so they don't represent that much load. Most of them are on a remote probe but that doesn't really help that much with load on the core server. The database is really just a lot of files and this seems to be the limiting factor.

I am exploring options to improve performance given that I was given the vanilla storage option by our server team.

I use the API a lot to create devices and sensors based on data from our wireless management application ( a device per access point - we have 15,000 ). The API eats up memory and a long script creating devices or sensors has the possibility of crashing the server because of memory exhaustion.

The PRTG Core server does not seem to scale beyond 6 CPU cores. It only uses the last 6 of my available 12.

My server team doesn't want to give me real hardware but if they can't give me the storage performance I need on virtual I will need to insist on real servers.

Created on May 29, 2019 7:29:48 PM by  Ed McGuigan (210) 1 1



Votes:

0

Your Vote:

Up

Down

Hello @GwigstaNummerEin

We do recommend to have hardware servers for an installation this large, but in order to improve the performance you are able to set the PRTG process to use all your 12 CPU cores available by setting the Processor Affinity in the task manager, you can refer to this guide Here. You can try setting the PRTG to use all 12 CPUs to see if the performance improves. This setting is reset in every reboot.

You can also try to increase the connection limit on VMware systems by following this article. Article

Created on May 30, 2019 5:49:47 PM by  Jonathan Mena [Paessler Technical Support]

Last change on May 30, 2019 5:50:24 PM by  Jonathan Mena [Paessler Technical Support]



Votes:

1

Your Vote:

Up

Down

Hi Jonathan:

I am just looking at a utility to make affinity settings persist through restarts because I restart every night. We have another PRTG server with 22 cores so that needs it too.

I would prefer to run on real hardware with NVME storage but my hands are tied by internal bureaucracy and standards.

One other measure I did take was to put nginx as a reverse proxy in front of the server and I also use Firefox because it seems to load the web server less and provide a much snappier response time than Chrome.

Thanks for the reply.

Ed.

Created on Jun 6, 2019 5:40:27 PM by  Ed McGuigan (210) 1 1



Votes:

0

Your Vote:

Up

Down

With PRTG we manage an older windows 7 peer to peer LAN with just 17 devices. The core/probe, also an older PC, was having performance issue with WMI sensors.

Installing WMF 5.1 packages solved our issue. It included new bindings to COM objects for the WMI, WinRM and Powershell for Windows 7 SP1 that were never pushed by Microsoft but are available for download.

https://docs.microsoft.com/en-us/powershell/scripting/windows-powershell/wmf/setup/install-configure?view=powershell-7.1

Created on Dec 4, 2020 4:56:08 PM by  aj (20) 1



Votes:

0

Your Vote:

Up

Down

thanks for posting. solution above also applies to

Windows Server 2012 R2 Windows Server 2012 Windows Server 2008 R2 Windows 8.1

and is relevant to large installs where there might be remote prob on older systems

Created on Dec 11, 2020 9:17:34 PM by  aj (20) 1



Votes:

0

Your Vote:

Up

Down

@Paessler

Could you maybe create the KB Articel from Scratch so it refects a 2021 Approach , the approach is rather general .

With SSD in Place a Defragmentation shouldnt be handled any more, we havent seen in doing so any adavantage.

I would be intrested if a Windows Server 2019 Core Installation is now a Days testet and approved through Paessler , are there any Evaluation already for REFS as FileSystem.

Performance Boost Expectations from current Storage Development like NVME SSDs.

Are there Plans may in the near Future "2 Year" Time Windows to Port the Software to an Appliance Typ OVA Style which can be used out of the Box on Virtualization Platform like Hyper-V , KVM , EXI ?

Created on Mar 12, 2021 8:57:29 AM by  mviel (0)



Votes:

0

Your Vote:

Up

Down

Hello @mviel We do overhaul articles on a regular basis but we handle it one at a time. You can refer to our manuals that are updated frequently, especially for VM setups: https://www.paessler.com/prtg/requirements

At the moment, different installation options are explored but there is nothing to announce at this time.

Created on Mar 17, 2021 6:58:13 PM by  Jonathan Mena [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.