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

[gcraenen]

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.

[SMabille · Accepted solution]

Hi,

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

Best regards,

Stephane

[Dave_Hall · Accepted solution]

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

[Adrian_Lewis · Accepted solution]

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.

[ISOffice · Accepted solution]

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

[stuartlawson]

Was using 6.2.0 for a while. Then, ever since Cloudflare had DNS issues a couple of weeks ago the memory usage on my 201E has gone to memory conserve mode within 5 days after a reboot. Grateful to the people here that posted comments. Did a diag sys top command and found that it was the dnsproxy process that was eating up memory.

I went to Security Fabric -> Automation and set up the following to run late every night:

diag test application dnsproxy 99

Memory usage drops back down to 20% and I don't have to monitor it every day now.

[stuartlawson]

More: The 6.2.1 update fixed the dnsproxy memory issue.

[Vinicius]

Hello,

Anyone having this issue on 6.2.1?

Every week i must restart those cause they run into conserve mode.

Already set-memory-threshold-green to 89 and red to 90.

I'm running 6.2.1 on a 30E and on 60E.

[Break16]

Vinicius wrote:

Hello,

Anyone having this issue on 6.2.1?

Every week i must restart those cause they run into conserve mode.

Already set-memory-threshold-green to 89 and red to 90.

I'm running 6.2.1 on a 30E and on 60E.

has anyone had any experience with version 6.2.1? is this problem now 100% fixed? are we safe to update to 6.2.1?

[zaphod]

i manage about 25 different Fortis on different locations, have most of them updated to 6.2.1 and no more conserve or memory issues. 

But my Models are minimum 60E or higher... maybe 30E is not the best model for 6.2.x.. 

[Dave_Hall · Accepted solution]

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

[zaphod]

Dave Hall wrote:

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

hm, dont have a problem with 6.2.1 but above i have quoted a workaround from other user here.

i thought this memory consumption problem is fixed with 6.2.1 but seems not...

have you upgraded from 5.x to 6.2.1 or from 6.x to 6.2.1?

greets

zaphod

[FortiET]

Yes, I am pretty sure that we was running 6.x some months, and then in July/August upgraded to 6.2.1

[Vinicius]

Hi!

I upgraded from 6.x

Do you know when will the 6.2.2 be released?

Thanks!

[Adrian_Lewis · Accepted solution]

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.