Kernaali Tools
FortiGate

FortiGate Conserve Mode: Diagnose Memory Pressure

Distinguish high memory use from an active conserve-mode event, collect bounded evidence, and avoid threshold or inspection bypass shortcuts.

Confirm conserve mode and its timing before treating high memory usage as a firmware leak. A memory percentage alone does not identify the consuming process, and a reachable GUI does not prove that all traffic is still inspected.

Applies to: FortiGate FortiOS 7.4.4 conserve-mode semantics and diagnostics. Applies to a single unit’s memory investigation, not an automatic reboot, HA failover or firmware downgrade procedure.

Validation: documentation-checked on . No device or lab test is claimed. Version references identify the documentation checked, not a firmware upgrade recommendation.

Read the actual state first

Read-only • FortiOS 7.4.4
diagnose hardware sysinfo conserve

Read the mode, total/used/freeable memory and the configured green, red and extreme thresholds. The documented defaults are exit at 82%, entry at 88% and extreme at 95%; inspect your own settings rather than treating these as universal operational targets. Extreme memory pressure can reject new sessions. FortiOS 7.4.4 conserve-mode reference describes these thresholds and inspection behavior.

Synthetic observation: “mode off, usage 74%” does not establish an active conserve event. “mode on” with a matching system event does. Record the timestamp and traffic impact so an earlier event is not confused with current state.

Correlate state, events and the recent change

In Log & Report → System Events, locate the memory conserve entry and exit around the reported outage. If the GUI is unavailable, the crash log can preserve relevant events:

Read-only • inspect privately; output can identify the system
diagnose debug crashlog read

Record the exact firmware build, hardware revision/RAM, uptime, enabled inspection mode and last relevant change. Compare conditions at similar traffic loads. A database update, increase in connections or a new inspection workload can coincide with memory pressure; a single coincidence is not a confirmed leak.

ObservationWhat it establishes / next action
High but stable memory, mode offCollect a trend and workload context; do not raise thresholds
Repeated entry/exit at comparable loadCompare event times with recent changes and collect a bounded process-memory snapshot for support
Only a named process grows over timeCheck that exact build’s known/resolved issues and obtain vendor confirmation before a version-specific fix
Reboots or CPU stalls without a matching memory eventInvestigate the crash separately; do not label every outage conserve mode

Understand why allowing traffic is not proof of health

The proxy antivirus failopen setting and the flow IPS fail-open setting are different controls. Depending on their values, an affected inspection path can allow uninspected traffic or refuse new sessions. Inspect the effective settings and verify the critical application and required inspection after recovery. Do not change fail-open simply to make a connection work.

A known issue is bounded by build, platform and trigger. For example, the 7.4.4 known-issues list contains model/workload-specific memory issues; it does not establish that every high-memory unit has one of them.

Choose the smallest justified intervention

The collection steps above require no configuration change or rollback. If the evidence points to a recent optional workload change, review a targeted reversal in a maintenance window with independent management. Do not kill processes, schedule periodic restarts, reduce security coverage or increase memory thresholds as a general first fix. If service is unstable, provide the redacted timeline and bounded evidence to vendor support through the organization’s approved channel.

After an approved change, compare memory behavior at representative load and complete a new application transaction through each affected inspection path. Confirm that conserve mode stays off through the relevant workload cycle. Restore only the recorded workload settings if the change fails; a full-device reset would destroy evidence and expand the outage. No continuous debug was enabled by these examples.

Technical references

Found an issue? Send a correction with a reproducible example.