On a 2 GB desktop FortiGate, conserve mode during FortiGuard updates can be caused by IPS signature-acceleration memory use. Fortinet documents cp-accel-mode none for that case. Confirm the model, update timing and IPS symptoms below before using it.
Read state and thresholds together
diagnose hardware sysinfo conserveCompare current usage with the configured entry, exit and extreme thresholds. The exit threshold is lower than entry, so memory can fall below the entry point while conserve mode remains active. Use the device’s displayed values rather than assuming the defaults.
Conserve-mode behavior depends on the inspection path and fail-open settings. Extreme pressure can reject new sessions; passing traffic is not evidence that required inspection is still active.
2 GB model enters conserve mode during FortiGuard updates
Fortinet’s IPS-update memory issue covers desktop models with 2 GB RAM. The related defect 1025114 can leave ipshelper/ipsengine in state D with high I/O wait after the update.
For the documented update-memory case, record the current value in show full-configuration ips global, then disable IPS signature hardware acceleration. With VDOMs enabled, enter config global first and leave it with end afterward:
config ips global
set cp-accel-mode none
endThis reduces update memory use at the cost of more CPU processing. Check CPU and conserve state through the next update; restore the recorded value if the tradeoff is unsuitable. A build already using none has this setting applied.
The related locked-process/high-CPU defect is fixed in 7.0.16, 7.2.11, 7.4.6 and 7.6.1 within those branches. Use a supported upgrade path for the model. Those fixes do not eliminate the update’s memory demand.
Memory fell, but conserve mode has not ended
Run diagnose hardware sysinfo conserve again. Memory must fall below the displayed exit threshold, which is lower than the entry threshold. Raising thresholds does not repair the memory shortage.
For a different growing process or failure unrelated to an update, the IPS workaround above is not established by that symptom. Keep the process/build observations for a matching vendor defect or support case instead of restarting arbitrary daemons.
Correlate the event with a trend
Open Log & Report → System Events and filter the time window for conserve-mode entry and exit messages. If needed, inspect the crash log:
diagnose debug crashlog readIn get system status, identify the model and build. Compare the conserve event time with the FortiGuard update time in Log & Report → System Events.
Identify a different process using the memory
get system status
get system performance status
diagnose sys top 5 20get system status identifies the model and firmware build; get system performance status shows memory, uptime and session counts/rate.
In diagnose sys top, press m to sort by memory. Record the process name, PID and the rightmost memory column over several five-second samples, then press q to stop.
Compare again under similar session load; if one process keeps growing at stable load, record its PID and build for a matching vendor defect or support case. Process fields and controls.