When planning large installations of PRTG Traffic Grapher with many sensors (>100) or with high traffic (>10 Mbit), there are several parameters to take into account that influence the maximum number of sensors that can be monitored using one single PRTG instance.

The number of sensors and the bandwidth volume that PRTG can monitor with one installation mainly depends on the monitoring technology and the monitoring intervals you use:

• The smallest CPU load is required for SNMP based monitoring. This is the recommended technology for scenarios with hundreds or thousands of sensors regardless of the traffic where per-IP and per-protocol accounting is not necessary.
• With NetFlow monitoring the bandwidth values that you can monitor is almost unlimited. This is the recommended technology for Cisco devices and should be considered for all high traffic networks (>20-50 MBit/s steady streams) if per-IP and per-protocol accounting is required.
• The most CPU load is required for Packet Sniffing. This technology is recommended for lower traffic networks (<50 Mbit/s steady stream) if per-IP and per-protocol accounting is necessary. In tests we were able to monitor a stream of 95 MBit/s on a 2.8 GHz Pentium 4 HT.

Please read on for details:

Details for SNMP Based Monitoring

Each SNMP monitoring request only requires some 200 bytes to be sent to a device and sent back and the data can be processed by PRTG very fast. We currently recommend not to exceed 2000 SNMP sensors to far on one PRTG installation, although there are active installations with 3000 sensors and more. The monitoring interval time is also important, doubling the interval almost doubles the number of sensors you can monitor.

Values for a Sample SNMP based Installation

When monitoring 100 sensors via SNMP with PRTG's default settings you will get the following data:

• While running the Windows GUI: About 25 MB memory
• While running as service: 10 MB of memory
• Less than 1% average CPU load on a 2 GHz PC (excluding usage of the internal webserver)
• About 12 MB of disk space per day for historic sensordata
• About 5-10 kbit/s of network traffic (excluding any requests to the internal webserver)

The values are described in detail below:

1. Number of sensor requests

There is a currently a limit of 200 sensor requests per second, respectively 300 busy sensors (see Details about the meaning of the “Busy Sensors” value in PRTG Traffic Grapher), built into the scheduler. The sensor request per second limit is equivalent to monitoring 6.000 sensors with an interval of 30 seconds or 12.000 sensors with an interval of 60 seconds.

One must take into account that also the time it takes for your device(s) (and your network) to answer the SNMP requests from PRTG can influence the maximum number of sensors - depending on the intervals. The following values for intervals are a rough guide based on real-world experiences. But for a specific network the values can be quite different. Only a test will show the real values for your network.

Less than 100 sensors: Recommended minimum interval of 5s
Less than 500 sensors: Recommended minimum interval of 30s
Less than 1000 sensors: Recommended minimum interval of 60s
Less than 3000 sensors: Recommended minimum interval of 120s
More than 3000 sensors: Recommended minimum interval of 180s

2. Memory usage

For each sensor the data for the four available graphs (live, hourly avg., daily avg., and custom interval) is stored in RAM. The number of values for a graph depends on the time period a graph will span. This period is set by the user. E.g. if you set the graph with hourly averages to a period of 30 days you will need 30*24 = 720 entries.

If you use PRTG with the default settings the number of data entries per sensor (for all 4 graphs) is about 1.200 entries. Each entry requires about 40 Bytes of RAM so you can calculate with about 50KByte per sensor with default settings. If PRTG is run as a service add an additional about 5 MB to the value calculated above. If you use the Windows GUI you will need considerably more memory. First add about 10 MB for the Windows GUI. Additionally about 250 kb per graph (shown on a panel), is necessary - while this graph is visible! As a rule of thumb you will need an additional about 1-2 MB per panel when the Windows GUI is running.

As soon as you switch from Windows GUI to the service (e.g. by simplying closing the Windows GUI), the memory usage will drop to the value calculated above.

3. CPU usage

On a 2 Ghz Intel machine you can expect a CPU load of about 5% per 1.000 Sensors with the 30 seconds default interval (or about 10% with an interval of 15s). Which means that on machines like that (or on faster ones) you will run into the sensor request limit mentioned under 1. before you get into any trouble with the CPU load.

4. Disk usage

Each active sensor with a default interval of 30 seconds uses about 120Kb disk space per day for the historic monitoring data. This sums up for each day PRTG is running unless you delete old data.

5. Network Traffic

50 sensors with a default interval of 30 seconds will cause a network traffic of about 500 Bytes/s. If you make use of the internal webserver this can add considerably more bandwidth to your traffic. You can calculate about 20kb per request of a sensor page with 4 graphs. Remember that the webpages of PRTG have an auto reload feature!

Details for NetFlow Based Monitoring

When NetFlow monitoring is used the main performance issue is the volume of NetFlow packets coming from the routers.  This value can be shaped by using longer accounting cycles in the router settings, so there is no real limit to NetFlow monitoring. For common installations we recommend to work with up to 50 Netflow Collectors (one collector per router) on one PRTG installation, but depending on the actual situation 25 or 200 may also be a limit. The average CPU load of the machine running PRTG should not exceed 70% to avoid packet loss.

Details for Packet Sniffing Based Monitoring

Each single network data packet of the data stream must be inspected and accounted for by PRTG, so CPU power is crucial. Our tests showed that a 1.7 GHz Celeron can monitor streams with 20-40 MBit/s without packet loss. A 2.7 Ghz Pentium 4 with HyperThreading was able to work with stream of up to 60-80 MBit/s. We recommend to keep the CPU load of the machine running PRTG below 70% to avoid packet loss. A good idea is to run a test for a specific network traffic using the freeware or trial edition.