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:
   

   [edit]
show | display set | match traceoptions

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.


2. 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

3. 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.


4. Check if the syslog has many files locally:
   

   show system syslog

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.