This article describes the following syslog message:
KERNEL:Process .* has exceeded 85% of RLIMIT_DATA
This message indicates that a process has exceeded the 85% limit of virtual memory allocated for the data-segment area (RLIMIT_DATA) of the process.
When a process is started, it is allocated a segment of memory in which to operate.
Each process has a limit of 128 MB.
The size of this data-segment area is referred to as the RLIMIT_DATA.
When a process uses 85% (108 MB) or more of this allocated memory, the system logs a syslog message similar to the following examples:
/kernel: Process (1039,lacpd) has exceeded 85% of RLIMIT_DATA: used 114716 KB Max 131072 KB /kernel: %KERN-5: Process (1635,ilmid) has exceeded 85% of RLIMIT_DATA: used 114692 KB Max 131072 KB /kernel: Process (92309,eventd) has exceeded 85% of RLIMIT_DATA: used 119792 KB Max 131072 KB /kernel: Process (1278,l2cpd) has exceeded 85% of RLIMIT_DATA: used 1925192 KB Max 2097152 KB /kernel: Process (31570,mib2d) has exceeded 85% of RLIMIT_DATA: used 469860 KB Max 512000 KB
The process for which the message was reported is listed in parentheses.
The amount of space used and the maximum size of the allocated space are also listed.
A process has exceeded the 85% limit of virtual memory allocated for the data-segment area (RLIMIT_DATA) of the process.
The message is informational and does not necessarily mean that the process will encounter problems. Problems are likely to occur if the process attempts to use more than its allotted amount of memory. For example, the process may become slow in processing the request, the process may stop working, the process may restart itself, and so on.
Perform these steps to determine the cause and resolve the problem (if any). Continue through each step until the problem is resolved.
1.Collect the show command output on the Routing Engine.
Capture the output of the commands below. Capture the output to a file (in case you have to open a technical support case). To do this, configure the SSH client/terminal emulator to log your session.
show system processes extensive show system processes extensive | match <process name> << Run this periodically to see how often the memory utilization is rising. show chassis routing-engine show log messages show system core-dumps
2.Analyze the output of the show system core-dumps command.
Was a core-dump file generated by the Routing Engine with a timestamp corresponding to the moment that the event message appeared?
Yes – Open a case with your technical support representative to investigate the issue further. Attach the information collected above to the case
No – Continue to Step 3.
3.Changes in the system/network?
Are there any recent changes being done on the router or in the network related to that particular process; for example, configuration changes, add more routes, provisioned new customers, and so on?
Yes – See if the changes are related to that process and revert those changes during a maintenance window to see if that helps to bring down the memory utilization of the process.
The commands below help to track changes in the configuration:
show system commit show system rollback X compare Y << X and Y are the commit number that you want to compare.
No – Continue to Step 4.
4.Analyze the output of the show system processes extensive command.
Monitor the memory utilization of that process using the following command:
show system processes extensive | match <process name> lab@Router-RE0> show system processes extensive | match pfe 87146 root 1 96 0 167M 120M select 205:22 0.00% pfed lab@Router-RE0> show system processes extensive | match pfe 87146 root 1 96 0 202M 155M select 274:03 1.71% pfed
If the size of the process remains high, or is steadily increasing as above, and you started noticing the problem related to the system or the functions related to that particular process, restore services by restarting the process. Many processes can be restarted from the CLI. To find out if the process you need to restart is one of them, use the command restart ?. The output of this command lists the processes that can be used with the restart command. It is recommended that you restart a process (depending on the process) only during a scheduled maintenance window, because it will impact traffic and/or services.
To collect more information before restarting the process, open a case with your technical support representative, and the engineer will work with you to collect any additional information needed.
Note that if the process cannot be restarted from the CLI, there are other ways to restart the process, as well as other methods to use to debug the issue. Contact your technical support representative for assistance.
After restarting the process, monitor the output of the show system processes extensive command to check the rate at which the process is consuming memory. Run this command several times at intervals of five to ten minutes for a day or more. If the memory usage does not go up, restarting the process resolved the issue. If JTAC was not involved and did not collect more information, determining what caused the process to cross the memory threshold in the first place is usually impossible. If the same process encountered this problem repeatedly, it may be possible to investigate the cause further.
If, after restarting, the usage rate grows steadily until the memory is exceeded again, there is a memory leak or some other internal software error.
5.If these efforts do not resolve the problem, contact your technical support representative to investigate the issue further.