CPU load > 95%

[#1]

I have two FortGate 800 connected in HA. The CPU load is more than 95% at all time. Diagnose sys top shows two instances of miglogd wich consumes 80% of the CPU and imd wich consumes the rest. What is the miglogd. Why does this deamon consume so much CPU. Can this deamon be stopped/restarted. How do I do that. Thanks for any advice.

[abelio]

Hello, you' re talking about IM proxy; you can restart it using CLI command: " diagnose test application im 99" same thing for log proxy. Maybe you' re running a firmware version which known bugs; check it out once again. regards

[#3]

My current status is V4.0 build 0291.100824 (MR2 patch 2)

[FortiRack_Eric]

There is a q&d way to restart this process if the solution Abelio mentioned doesn' t work with diag sys top identify the process id of miglogd and then diag sys kill 11 <proc-id> this will kill the process and it will restart automatically cheers, Eric

[#5]

Thanks. Killing the process certanly helped. I killed one of the two miglogd processes and now I have one miglogd process sleeping. The system also responds much faster. Strange thing though, the dashboard still shows CPU usage 92-99% Diagnose sys top show avg usage 13% with imd using 90% of this.

[Victor]

I am experiencing a similar problem. I am running an interim code 298 on the new 3040B and in peak traffic the CPU can reach 95%. What I find interesting is the traffic still flows and the policies are still enforced. Was that the case with your situation or was traffic performance compromised. Victor P.S.: I do have a call ticket open with Fortinet on this issue.

[veechee]

magnnyb, There is a bug in the current MR2 release that can lead to 95%+ CPU usage when traffic shaping rules are in use; the Bug ID is 129497. I have had it occur a couple of times after about 2 weeks of uptime on a FGT-60C unit. Your problem sounds similar, because the second time this happened to me, I didn' t noticed until 5 PM, and no user had complained all day about network problems, even though CPU usage was at 99.9 percent. The logs never showed any conserve or fail mode. I' m told by support that Bug ID 129497 is fixed in the next release, and in the meantime, here are the commands they gave me to confirm if this is in fact the bug you are affected by: Run these commands:

diag deb en

diag deb app authd 255

Normal output message:

message_loop: checking timeouts

when authd generates High CPU usage you might get this output:

authd_traffic_quota.c:98 authd_ts_read: called

[Victor]

Thanks for the info. I do have one traffic-shaping policy but it is not active and was centred on limiting the ftp updates that saturated our internet connection when the majority of 20,000 workstations started up after a 2 mo. hiatus. At present, we are also not using authentication (I assume that is what the authd daemon is for). Rather our policies/profiles are based on src/dst addresses. My issue seems to be with a brand new platform and special builds branched off of the general release. Fortinet Tech support & I are working on isolating the source of the issue and I will post our findings when we have some answers.

[veechee]

I don' t use authentication of any kind either, so that is not a necessary condition to by plagued by the bug I' ve experienced. Look forward to hearing what you find out with support.

[red_adair]

miglogd the the Logging-Daemon. It' s responsible for sending Logmessages to Syslog or FortiAnalyzer. The Daemon is optimised for sending Logfiles in binary Format to FortiAnalyzer. When you' re using Syslog it has extra work to do to convert the Binary Format into " Text" first and send it to syslog. -R.