Created on 04-26-2019 01:08 AM
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.
Solved! Go to 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
NSE4/FMG-VM64/FortiAnalyzer-VM/6.0 (FWF30E/FW92D/FGT200D/FGT101E/FGT81E)/ FAP220B/221C
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.
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.
@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
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.
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.
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
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!
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.