Support Forum
The Forums are a place to find answers on a range of Fortinet products from peers and product experts.
New Contributor

Several problems high memory and cpu usage blocking WAN connection after upgrade to 6.2



After upgrading from 6.0.4 to 6.2 I have problems with WAN connectivity falling out. I'm getting this message in de Fortios GUI:


Conserve mode activated due to high memory usage


I have tried to downgrade to 6.0.4 but can't with the error message that it failed beacause it cannot download the file from fortiguard. Help.

5 Solutions



Download the image from the Fortinet support website and upload/apply it from your browser.


Best regards,


View solution in original post

Honored Contributor

This is by no means a fix, but a work-around is to have the fgt perform a daily reboot. 


config system global set daily-restart enable set restart-time <time value> end

NSE4/FMG-VM64/FortiAnalyzer-VM/6.0 (FWF30E/FW92D/FGT200D/FGT101E/FGT81E)/ FAP220B/221C

View solution in original post

NSE4/FMG-VM64/FortiAnalyzer-VM/6.0 (FWF30E/FW92D/FGT200D/FGT101E/FGT81E)/ FAP220B/221C

Vinicius wrote:

Do you know when will the 6.2.2 be released?

No specific dates are available only targeted dates which can slip if any issues are identified. Currently target though I hear is this week.

View solution in original post


Hi all,


We upgraded our 100D appliances to 6.2.2 a week ago and noticed a slight improvement in GUI performance when viewing logs in Log & Report. However, when filters were applied the CPU once again spiked to 90+% with multiple instances of the 'log_se' process running.

I have an ongoing support call logged with Fortinet and their TAC Engineer (cheers Kevin!!) suggested that I fail over to the 'slave' appliance to see if the issue could be replicated there. To my surprise, it wasn't. The GUI was responsive and I could apply filters to viewing logs and the CPU didn't spike. The only difference between the appliances was that the 'master' appliance had used 75% of it's disk for log storage and the 'slave' appliance only 2% (we are running active-passive). When viewing logs (with filters applied) on the 'slave' appliance the 'log_se' process didn't even appear when I ran 'diag sys top'.

Long story short, on failing back to the 'master' appliance I deleted all logs on the local disk (execute log delete-all) and can now view logs, with multiple filters, quite easily and without overly stressing the CPU. We syslog traffic logs in real-time to a third party product, so it isn't critical for us to retain logs on the appliance's hard disk for extended periods of time.

Querying local disk logs, particularly if there are many of them, possibly results in high CPU usage due to the high i/o requirements to do so.

Whilst this may not be relevant to many others in this discussion, I thought I would share our experience anyway.


Best regards,


John P

View solution in original post

Valued Contributor II

@gcraenen, did you open a support ticket with TAC?  I known they've fixed a number of bugs between 6.2.0 and 6.2.3, some specific to ipsengine, but if your specific issue and repro case hasn't been reported them then it's unlikely to have gotten fixed.


Not saying that 6.2.3 is stable enough, though!  We usually wait till the .4 releases to start testing them for possible production use.  I'm reasonably hopeful

View solution in original post

New Contributor

Update to 6.2.2, the last firmware


6.2.2 still has memory issues as well. TAC said a hotfix is coming in the next few days.


we have 3 fortigate 800D, one with 6.2.2, other with 6.2.1 and the last with 5.6.6

6.2.2 has a high memory usage in the proccess wad, once a day we have conserve mode, the only fix i found is to create an auto-script to restart wad every 4 hours.

On the other hand, it also presents problems with ipsmonitor, the use of cpu grows up to 100% and is not solved by restarting the ips. conclusion: 6.2.2 is not for production


6.2.1 is much better than 6.2.2



6.2.0 - Memory leak issue forced reboot after conserve mode

6.2.1 - Chrome wouldn't load certain websites due to a QUIC error

6.2.2 - Just had to reboot after 18 day uptime due to memory usage


So far not great with 6.2.x


We did see some high cpu issues on ipsengine, which have been fixed in interim builds of 6.2.3. Also, wad has memory leak issue which has also been fixed in 6.2.3.


Any idea when 6.2.3 will be available for download?


Bump, anyone that have any information when 6.2.3 will be released?


Robin Svanberg Network Consultant @ Ethersec AB in Östersund, Sweden

Robin Svanberg Network Consultant @ Ethersec AB in Östersund, Sweden

We are seeing this with several Fortigate 60E's that are running 6.0.6. I just had to have a client power-cycle theirs 10 minutes ago and another client about 4 hours ago. I didn't get a chance to see what process was consuming the memory since I couldn't even get logged in to the GUI before it was power-cycled. I'm really not sure what to do. Really don't want to implement the daily restart script that someone posted on here, that will just lead to us getting offline alerts from our RMM system for devices on those networks. 




6.0.7 is out now isn't it? It does list quite a few fixes. Can you try that perhaps?


I'm running 6.2.2 on the 60Es and it seems a lot better than the original 6.2 release so that's also an option perhaps now. However, I'm still seeing memory issues on 6.2.2 on a 30E. 6.2.3 is rumoured to be close too.


Kind Regards,






Yeah, I saw that 6.0.7 was recently released, but I haven't went through the release notes yet to see if anything like this was addressed. I don't think Fortinet has ever came out and said there is a bug in any version except 6.2.1, so I'm not real hopeful that it will be listed as one of the fixes. 


Select Forum Responses to become Knowledge Articles!

Select the “Nominate to Knowledge Base” button to recommend a forum post to become a knowledge article.

Top Kudoed Authors