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

[ISOffice]

Hi all,

We have 2 X 100D Hardware Appliances running firmware version 6.2.0-build0866 in NAT (Flow-based) Mode (HA: Active-Passive).

We too are seeing periodic spikes in CPU usage which occasionally puts the appliance in 'conserve mode'.

However, on running the 'diag sys top' command, I'm seeing a process called 'log_se' as the main culprit of resource usage, rather than 'ipsengine'. I also have an automated task configured to restart the IPS Engine out-of-hours.

I understand the 'log_se' process to be related to logging and the CPU usage spikes when I am viewing Web Filter, Application Control, Local Traffic logs etc. in the GUI. I can't run queries on these logs within the GUI for any length of time in fear of spiking the CPU and pushing the appliance into 'conserve mode'.

I'm wondering if both of these issues are related and it is not only the IPS Engine which is hogging system resources.

I will pose the question to Fortinet Support to get their view on it and will post any developments.

Best Regards,

John P

[ISOffice]

Hi all,

Quick update.

Fortinet Support are insistent that my issue is caused by the known memory leak in the IPS Engine (Bug ID: 0546399) and that it will be rectified in Version 6.2.1.

This version is due for release "mid of July" with the caveat "release dates are as-is and still subject to change".

Best regards,

John P

[andrewbailey]

John P,

Great your issue has a solution. There are certainly workarounds posted in the forum that can help in the meantime.

I've having similar issues with conserve mode and raised a ticket 22nd May. I was originally told the 6.2.1 release would be end of May, then middle of June and then last week 3rd of July (ie today).

It seems the info you have given suggests the release date has slipped again and potentially that Fortinet are struggling to fix the issues.

Personally I think it's poor that something as serious as this has taken so long to be resolved. Even worse that we are being given dates that keep slipping.

Kind Regards,

Andy.

[andrewbailey]

John P and others,

I'm told the revised release date is now 8th of July- next Monday. Hope that's a useful update for everyone- or at least someone.

Happy to July 4th for everyone in the USA.

Kind Regards,

Andy.

[ngocanh87]

I use FG200E & receive answer

Bug is already raised for this issue and developer is working on the same

Most probably it will resolve in 6.2.1 which will release at end of the July month.

If utilization Impacting on your production network ,Requesting you to rollback to previous working version or 6.0.4 which is more stable version “

[mike_dp]

Just like previous major releases, just update when the new release reaches the 3rd or 4th version. 6.0.5 is now stable with the issue of the WAD process high memory usage. We will wait for at least 6.2.4 to update to 6.2 from 6.0.

[ShawnZA]

On 6.2.2 and same issue, so still not fixed... When is 6.2.3 being released?

[ricsend]

Hi, I Have the same problem today in FG200E (6.2.0), What is the prevision for release of the 6.2.1 ??

[Frank_Baschin]

Yesterday we had the same problem. Temp. solved with disable alle policy services and install the ips reboot script, which was posted in this forum. It seems that the IPS had a memory leak. Ticket is open 

[BMS]

Experiencing the same since upgrading a 61E from 6.0.5 to 6.2.  For me it's the WAD process that send the device into Conserve Mode.