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

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

Hi,

 

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
SMabille
Contributor

Hi,

 

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

 

Best regards,

Stephane

View solution in original post

Dave_Hall
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
Adrian_Lewis

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

ISOffice

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

tanr
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

79 REPLIES 79
SMabille
Contributor

Hi,

 

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

 

Best regards,

Stephane

gcraenen

Thanks, that worked and everything is working ok again. Fortios 6.2 absolutely is not ready for our production environment.

nomeursy
New Contributor III

Same problem here. After upgrade a Fortigate 30E, from 6.0.4 to 6.2.0, average MEM usage went from 65% to 75%, causing the Fortigate to go in and out of "Conserve mode". SSL-VPN does not except connections and WAN traffic is blocked several times a day. Downgrading back to 6.0.4 solved the problem.

andrewbailey

Same problem here too.

 

I have a fairly lightly loaded 60E running 6.2 (no more than 800 sessions maximum) and have had at least one "Conserve Mode" event a week since the upgrade.

 

For me it's not too much of a problem- but certainly indicates 6.2 has some issues with memory management.

 

Kind Regards,

 

 

Andy.

 

 

rkhair

We are getting same thing, memory is at about 36% when rebooted, then creeps up slowly every day untill the FW goes into conserve mode, so we have to reboot it and go through the cycle again. Hopefully they fix the memory leak fast.
thuynh_FTNT

Hi all, thank you for reporting the issue. For each of your cases, can you check which process is taking up the memory when the FGT goes into conserve mode? "diagnose sys top" There is a known memory issue with IPS engine which is fixed in FortiOS 6.2.1

rkhair

Is there any way to get 6.2.1 or at least an ips engine to fix it till 6.2.1 is officially out?
Break16
New Contributor

Hello 

 

same problem here. my company stopped working for nearly 2 hours because we could not find the problem until I arrived in the office to check the firewall ... after getting access to the firewall I saw the error: "Conserve mode activated due to high memory usage"

 

can forginet fortinet/fortigate people help please? why we have to wait so long time to get this fixed?

 

user gcraenen reported this 3 weeks ago!

rkhair
New Contributor

i have an open support ticket with them... its a problem with the ips monitor.. temp fix at the moment is to run this command in a CLI:

 

diagnose test application ipsmonitor 99 

 

doing that restarts the ips monitor and the mem usage drops all the way back down again, they said it will be fixed in 6.2.1.

Announcements

Select Forum Responses to become Knowledge Articles!

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

Labels
Top Kudoed Authors