|
1) Check which part of the unit is consuming the most CPU i.e user/kernel/Soft IRQ:
# get system performance status
2) Check the demons consuming the most CPU.
It is possible to do not see any demon consuming the CPU, but the CPU is at 100% which could be due to the Layer2 broadcast, multicast, etc. hitting the FortiGate:
# diagnose sys top 2 50 <----- Run it for 15 seconds and press q to quit.
# diagnose sys mpstat 2
# diagnose hardware sysinfo slab
# diagnose hardware sysinfo memory
3) Collect the CPU interrupt:
# diagnose hardware sysinfo interrupts
4) Collect general session info:
# diagnose sys session stat
# diagnose sys session full-stat
# diagnose sys session exp-stat
# diag sys session list
5) session dirty:
# diagnose sys session list | grep \ dirty
# diagnose sys session list | grep =dirty
# diagnose sys session list | grep \ dirty -c
# diagnose sys session list | grep =dirty -c
6) collect session np offload info:
# diagnose sys session list | grep offload
# diagnose sys session list | grep protocol-not-offloadable -c
# diagnose sys session list | grep total
7) To confirm if the routing change is not causing the CPU to spike( run the command multiple times to confirm if the Fib version is not changing):
# diagnose sys vd list
# diagnose sys cmdb info - Run 2 to 4 times
8) Collect the CPU profiling for the cores consuming high.
In case multiple cores are consuming high CPU then, it is not necessary to put a filter:
# diagnose sys profile cpumask <ID of the CPU running high>
'# diagnose sys profile start': wait for a couple of minutes before stopping the profiling.
Take another Putty session to ensure the specific CPU cores filtered are still spiking:
# diagnose sys profile stop
# diagnose sys profile show
# diagnose sys profile show order
# diagnose sys profile show detail
# diagnose sys profile module
9) Take the dump of the demon causing high CPU:
# diagnose sys process dump <PID>
# diagnose sys process pstack <PID> <----- To find out the stacks for the process.
# diagnose sys process trace <pid>
|
