Support Support Downloads Knowledge Base Case Manager My Juniper Community

Knowledge Base

Search our Knowledge Base sites to find answers to your questions.

Ask All Knowledge Base Sites All Knowledge Base Sites JunosE Defect (KA)Knowledge BaseSecurity AdvisoriesTechnical BulletinsTechnotes Sign in to display secure content and recently viewed articles

[SRX/J-series] g_down process is going high; CPU utilization is going high; idle CPU down to 0%



Article ID: KB20989 KB Last Updated: 05 Mar 2017Version: 5.0
This article describes the issue of the g_down process being high, which causes the CPU utilization to reach 100%.

The g_down process is more than 2% and increases rapidly. This can be identified by repeatedly using the following command:
root> show system processes extensive | match g_down
4 root 1 -8 0 0K 16K - 0 1:27 2.00% g_down

root> show system processes extensive | match g_down
4 root 1 -8 0 0K 16K - 0 1:27 2.30% g_down

root> show system processes extensive | match g_down
4 root 1 -8 0 0K 16K - 0 1:27 3.50% g_down

root> show system processes extensive | match g_down
4 root 1 -8 0 0K 16K - 0 1:27 10.20% g_down
As g_down increases in the CPU, the kernel also increases; as seen with the following command:
root> show chassis routing-engine
CPU utilization:
User                  60 percent
Background       0 percent
Kernel               40 percent
Interrupt              0 percent
Idle                      0 percent
Model                   RE-S-1300
Serial ID              9009057983
Start time            2011-04-25 12:26:05 UTC
Uptime                6 days, 22 hours, 47 minutes, 17 seconds
Last reboot reason   0x2:watchdog
Load averages:  1 minute   5 minute  15 minute
                              0.00           0.00           0.00
The high percentage of the g_down thread in FreeBSD indicates that higher level entities (that is user processes) are trying to access physical devices, such as disk/storage/memory/IO, with such a high rate that there is a resource crunch. This further takes the kernel processes to high values. So, you will see the g_down process high, at the same time as the kernel level processes.

To find the cause, you need to check if there are many traceoptions enabled, the system storage is high, or the memory is highly utilized.

The issue, most likely, can be traced back to the traceoptions:
  1. Review the enabled traceoptions:
    show | display set | match traceoptions
  2. Deactivating the traceoptions mostly solves this issue. Certain users deactivate the filters, rather than the traceoptions. This is counterproductive, as the traceoptions will trace every packet in the firewall.

  3. Review the system storage for the component that has high usage. If /var/log/ or /var/tmp/ is heavily consumed, then empty /var/log/ and new additions in the /var/tmp/ directory.
    run show system storage
  4. Review the amount of logging that is being performed:
    show | display set | match log
    show security policies | display set | match log
    It should not be very high,for example, more than 100 policies logging at the same time. The limit depends on many factors and recommendation should be sought, if logging is necessary.

  5. Check if the syslog has many files locally:
    show system syslog
  6. If the number of files are many, try to reduce the unnecessary or redundant ones. Recommended: Use of remote syslog servers will reduce storage needs in the Compact Flash(CF).

  Contact your technical support representative, if the issue still persists.
Comment on this article > Affected Products Browse the Knowledge Base for more articles related to these product categories. Select a category to begin.

Getting Up and Running with Junos

Getting Up and Running with Junos Security Alerts and Vulnerabilities Product Alerts and Software Release Notices Problem Report (PR) Search Tool EOL Notices and Bulletins JTAC User Guide Customer Care User Guide Pathfinder SRX High Availability Configurator SRX VPN Configurator Training Courses and Videos End User Licence Agreement Global Search