Do not change these parameters in production environment without consulting ITRS Client Services. Inappropriate values could adversely impact the operation of your system
A NetProbe log entry like this means the built-in memory protection feature has been triggered:
- ERROR: NetProbe Restart Message: IMPORTANT - Contact your support provider; if supported directly by ITRS then mailto:email@example.com (0) otherwise your usual support contact
This is there as a basic way of preventing memory leaks but can sometimes be triggered by valid growth in the NetProbe memory usage.
This can be tuned using environment variables / registry settings but it is usual to look at the underlying cause first in case it could be a real leak.
The basics are that the NetProbe takes a snapshot of it's memory usage 10 minutes after start-up of a gateway connection or subsequent re-configuration. If the memory foot-print then exceeds that by a factor of 2 (by default) you get the message you see and a restart.
Here are the config settings, but please do not change unless necessary:
- DISABLE_MEM_PROTECTION (set to true to stop probe from restarting due to memory footprint doubling)
- MEM_PROTECTION_RATIO (e.g. 3 means memory must triple before netprobe restarts).
- LEAK_MEMORY (set to true to make netprobe leak - 5 mb per sample I think ? you can use this to test above).
- MAX_MEM_SIZE (set in MB, e.g. 500 means maximum memory size of 500mb for the Netprobe)
Environment variables on UNIX.
Registry keys on Windows. If NetProbe is run as a service, add the keys to HKEY_LOCAL_MACHINE\SOFTWARE\NetAgent\NetprobeNT. If NetProbe is run in command line, use HKEY_LOCAL_MACHINE\SOFTWARE\NetAgent\netprobe.windows.
Default for MEM_PROTECTION_RATIO is 2.
You can observe where the usage is by logging memory usage between samples. You have to enable "SAMPLING" and "SAMPLINGMEM" under the debug tab of the probe config - add two new rows to the top Debug entry and put SAMPLING in one Module and SAMPLINGMEM in the one below, no other settings.
Now, after saving the config, you should see the memory usage on entry and exist from each sampler.
There is a realistic chance that the star-up of some samplers or the sub-systems that they are monitoring come much later than the probe itself as a result of Active Times or trading times etc. and that this memory usage is valid. You have to judge!
Setting up Memory Debugging
- Open your Gateway Setup Editor and select the Probe you want to check for the memory leak.
- Once you have selected the probe, click on the 'Debug' tab located above.
- Then click on the 'Add new' on the Debug side and add the following modules:
- Also add '*' under Sampler to ensure that it would be able to check all instances.
To know if Debug setting is running, check on your NetProbe logs:
SAMPLING and SAMPLINGMEM should come in as a set (IN and OUT). Sample below:
- Action that samples data
- Default sampling interval : 20 secs
- Memory consumption from the hardware
- Allotted memory consumption (default)
- Actual memory consumption
- Memory difference can be seen in this part
- Check for the memoryDifference, if result is 0 bytes then there is change because of this sample. If it is greater than 0 bytes then it means that the plug-in has either allocated memory for persistent data (e.g. a new trigger in FKM) or it has memory leak. A negative value means that the plug-in has returned memory to the system as it frees up resources.
- Sample below shows that the MQ-QINFO Plug-in has memory leak.