NAM Probe capacity considerations

The most important parameter related to NAM Probe capacity is the amount of traffic that it can process.


Starting with NAM 2018, components have been renamed:

DC RUM 2017 May release Dynatrace NAM 2018 release
RUM Console NAM Console
Central Analysis Server (CAS) NAM Server
Advanced Diagnostic Server (ADS) Advanced Diagnostics on Demand feature of NAM Server
Agentless Monitoring Device (AMD) NAM Probe

For the analysis of simple traffic, the volume that can be processed is limited mainly by the CPU speed of the NAM Probe. Analysis of complex traffic involving large numbers of distinct sessions and users can use large amounts of memory, which becomes the limiting factor.

A NAM Probe is designed to write a summary analysis to disk every five minutes (subject to configuration), so no substantial backlog or analysis history is lost if the system is forced to restart due to memory overrun.

However, if CPU resources are the bottleneck, no restart occurs, but instead packets are dropped because the CPU does not accept from the network interface card more than the amount of traffic it can cope with.


If the NAM Probe can cope with the traffic for the first few hours of peak time without restarting or dropping packets, it should be able to handle similar traffic all the time.

NAM Probe monitoring interval

By default, NAM works with five-minute monitoring intervals. This means that the NAM Probe monitors all relevant traffic that is directed to the device, but it produces measurement data every five minutes. Then the report servers take the data, process it, and store it in the database for reporting purposes.

NAM Probe load sharing

It is possible to configure two or more NAM Probes to receive the same traffic, with each analyzing only a part of that traffic.

Load sharing between a number of  NAM Probes

This approach requires that an exact copy of the traffic be sent to each NAM Probe, subject to data center architecture and available hardware. Such load sharing will immediately divide the load by the number of NAM Probes, and thus correspondingly lessen the resource (CPU and memory) usage of each NAM Probe.

Sometimes tapping a mirror port cable is a good solution. Alternatively, you may be able to use Gigamon mirror port sharing. Note that a Gigamon switch can provide load sharing functionality by itself, which is a better solution if more than three or four NAM Probes are to be used in such a setup. However, do not oversubscribe the mirror port. Refer to the vendor documentation for details on checking loads.

Load sharing inside a data center is not useful if there is a small number of monitored client-server pairs or if the distribution of load between the different pairs is very uneven. Automatic load sharing is designed to split the processing evenly if the load distribution is fairly even between a large number of the client-server IP pairs. Therefore, if you have a large number of client-server pairs but the bulk of the traffic is generated for only a few pairs, the statistical load sharing based on IP combinations will not work properly.

To achieve load sharing for a small number of client-servers pairs, you can configure these specific addresses explicitly in the NAM Probe configuration rather than rely on automatic load sharing based on IP combinations.