Hello,
on a side note, I found the bug below. The bug details the ASR1K, but maybe the recommended EEM script works in your case as well:
memory leak in smand process on active RP
CSCsw33723
Description
Symptom:
The smand process memory footprint increases over time and can eventually run out of memory, reporting:
%PLATFORM-3-ELEMENT_CRITICAL: R0/0: smand: RP/0: Committed Memory value n exceeds critical level m
Conditions:
A small memory leak in the smand process will occur every time an ASR [show | set | clear] platform [software | hardware] command is executed. show ip nat translations causes the same symptom. The longer the command output, the faster will the leak be.
Under most normal operations this leak will not cause any problems. However, if an environment has been configured whereby a series of commands are left running continuously over a long period of time the memory leaks will add up and the process size will noticeably increase. In some cases the process will run out of memory and crash.
Workaround:
[1] For very long outputs, like show ip nat translations verbose with tens of thousands NAT entries, try using other means for gathering information, like SNMP or netflow export.
[2] It is safe to periodically restart the smand process. The frequency should not be less than a thirty minute period.
The frequency with which the process should be restarted will depend on how frequently the impacted commands are executed. The process size can be tracked via the command:
show platform software process list RP active name smand
The command to restart the process is:
test platform software process exit shell-manager RP active stateless
This can be automated using an EEM applet:
event manager applet restart_smand
event timer cron name "restart_smand_cron" cron-entry "1,31 * * * *" maxrun 120
action 1.0 cli command "enable"
action 2.0 cli command "test platform software process exit shell-manager RP active stateless"
action 3.0 syslog msg "EEM applet restart_smand has restarted the shell-mamager process on active RP"
Above applet will restart the process at 1 and 31 minutes after a full hour. Note that after a restart of the shell-manager process it may take a minute before the next instance of the process is available for use. Existing VTYs will not be dropped during the restart of the process.
Further Problem Description:
The problems can be mitigated by reducing the frequency with which long running scripts containing the impacted commands are being executed. This, in combination of a process restart, will keep the problem under control.
Customer Visible
Notifications
Save Bug
Open Support Case
