When memory usage is very high and increases very fast in a short period, it might be a memory leak issue, and it can be analyzed by the following steps.  Note that memory increase does not always mean a memory leak. A memory leak issue usually has these phenomena: Very fast and abnormal memory increase (usually with common or low traffic levels). In a scenario where a leak happens in a matter of minutes or even seconds, manual log collection might be infeasible. An automated monitoring script such as TeraTerm script is highly advised in these cases. Continuous memory increases without being de-allocated. Used memory is not de-allocated even after traffic drops or stops.
The most important thing for troubleshooting a memory leak issue is to locate which module, process, or function causes the memory increase. Â
System Information.
Collect the output of the following commands:
get system status
get hardware status
diagnose hardware sysinfo memory
diagnose hardware sysinfo conserve
diagnose hardware sysinfo cpu
diagnose hardware deviceinfo disk
diagnose system session stat
Performance Monitoring.
Run the following command five times, with an interval of one minute between each execution:
get system performance status
Resource Utilization.
CPU: Run the following commands for approximately 30 seconds, then press Ctrl+C to stop them.
diagnose sys top 1 20
Memory usage:
diagnose sys top-mem
diagnose sys top-s '-s mem'
Crash Logs.
Replace YYYY with the four-digit year, MM with the two-digit month, and DD with the two-digit day:
diagnose debug crashlog read | grep YYYY-MM-DD
Run 'diagnose sys top 1 20' to check the top-utilized resources, and based on the top-utilizing resources, collect further logs for them. Press Shift+M to sort the output of the above command by memory.  Run 'diagnose hardware sysinfo memory' to gain an idea of the allocated memory of current usage of firewall resources.
 For example, in the following:
diagnose hardware sysinfo memory
MemTotal: 1963860 kB
Cached: 448948 kB
Active: 932748 kB
  The well-known processes for memory leaks are WAD, IPS, fgtlogd, and others. In the event of memory leak issues, always refer to the release notes of the known issues of the firmware.
Refer to the article below to collect logs in case of WAD, IPS, and other processes consuming the memory. Based on the logs, it can be identified if there is a leak or if any network condition is triggering high memory usage. See the WAD section of the CLI Troubleshooting Cheat Sheet.
Refer to this article if IPS memory optimization is needed:Â Technical Tip: IPS memory optimization steps. Â Another common scenario is slab leaks. Slabs are kernel objects for dynamically allocating memory. In a slab leak, these slab objects are not getting deleted, and the device eventually runs out of memory.
Example:
Â
diagnose hardware sysinfo memory
MemTotal:Â Â Â Â Â Â Â 2042016 kB
MemFree:Â Â Â Â Â Â Â Â Â Â 94896 kB
Cached:Â Â Â Â Â Â Â Â Â Â 421136 kB
Active:Â Â Â Â Â Â Â Â Â Â 526904 kB
Slab:Â Â Â Â Â Â Â Â Â Â Â Â 960144 kB
Almost half of the memory is allocated in the slab.
In these kinds of cases, it is impossible to release this memory with some kind of command. Only a reboot will release the memory.
It is possible to see which slab objects are using up the memory with the command 'diagnose hardware sysinfo slab'. It will show the number of objects and their size, which can be used to calculate the total size of a specific slab type.
Note: If 'diagnose system top-summary' is deprecated, refer to Technical Tip: Deprecated of command '# diagnose sys top-summary'.
Related article:
Troubleshooting Tip: Memory debugs needed when creating a bug ticketÂ
| 
