When monitoring traffic with a large number of users but of relatively low volume, the NAM Probe may exhaust the available memory. In such environments, the memory limit problem usually appears before the CPU exhibits high utilization problems.
The reason for this is that when a NAM Probe is analyzing traffic, it uses memory to build a logical representation of each new TCP session. The larger the number of new or unfinished TCP sessions, the more memory is needed.
This problem is more likely to occur in:
- A public website with many users who view several pages on the site, such as a news portal.
- Large enterprise environments with enabled monitoring of default software services.
- High-volume areas such as high-speed interfaces (40 G) or Internet backbones. If you identify memory size as the limiting factor, first minimize the traffic that introduces the complexity. You can also take several other actions:
- In Internet-facing environments, place the NAM Probe after the first firewall, to filter all non-essential Internet traffic.
Important: You can move the NAM Probe behind the firewall only when the firewall does not alter TCP handshake timings and lead to wrong Client RTT measurements.
- Optimize your NAM Probe configuration settings.
Follow the general guidelines that relate to CPU and memory usage throughout NAM Probe configuration. In particular, configure the NAM Probe to use user-defined software services only, if this agrees with your monitoring requirements. For more information, see Configuring NAM Probe Scalability Options.
- Make sure the NAM Probe does not see unidirectional sessions.
This can happen if the NAM Probe is incorrectly attached to a network in which asymmetric paths are used, so that it sees only one side of each conversation. In such cases, the NAM Probe allocates session-processing resources as each session apparently starts, but then it waits indefinitely for the session to progress or close. Eventually, a timeout mechanism engages to free resources, but until that happens, they are allocated for an unnecessarily long time. You can check this in Discovery reports.
- Consider reducing the reporting interval or lowering the TCP session timeout limit or both.
However, this may have unacceptable effects by increasing the size of the report server database.
- Consider using NAM Probes in a load-sharing configuration by duplicating the data feed or using intelligent switching. You can configure two or more NAM Probes to receive the same traffic with each analyzing only part of it.
- Consider upgrading your 32-bit NAM Probe to a 64-bit machine.
Apart from the simple but not always sufficient measures listed above, the best way to avoid the memory limit issue on 32-bit machines is to upgrade the NAM Probe to a 64-bit machine.