Fortigate 40F firewall upgrade firmware 7.2.12 to 7.4.12 issue

Hi ​@Kkhude 

can you share below output to determine the cause

get sys stat
diag sys top >> ctrl+c to stop it
get sys performance status
diag debug crashlog read

diag sys session stat

Right Now Firewall Working Properly but after upgrade in 1 month 3 time goes to memory conserve mode

Your output actually tells the story, the staff snapshot of 52 percent just caught it after it had already recovered.

What the data shows. At capture time the box is lightly loaded: memory 52 percent used, CPU basically 100 percent idle, around 500 sessions and 6 Mbps average. So this is not a traffic or sizing-by-throughput problem. The conserve events are about memory footprint, not load.

The crashlog is where the conserve mode is visible. On several dates you see scanunitd, voipd, wf_monitor and quard all killed in the same second with status 0xf and 0xf00, for example 2026-01-08 02:08:08 and 2026-01-09 19:37:39. That simultaneous cull of the memory heavy daemons is exactly what conserve mode does to claw back RAM, which is also why memory looked fine by the time you ran the commands. So the box is genuinely entering conserve, then recovering by killing those processes.

Two consumers stand out:

• scanunitd is in the cull list every time, which points straight at the proxy and scan stack.
• sflowd is being killed and restarted almost every single day at a consistent time, all the way from January to June. That means sFlow is active and the daemon is churning continuously, which is pure overhead on a 2 GB box.

The avdb_patch segfault you may notice in the log was on v7.2.12, before the upgrade, so ignore it for this issue.

Root cause. The 40F is a 2 GB RAM model, and 7.4.12 has a noticeably larger baseline memory footprint than 7.2.12. On 2 GB hardware that leaves very little headroom, so even a lightly loaded box like yours tips over the conserve threshold a few times a month, then recovers by culling daemons. This is expected behaviour for 2 GB models on 7.4, and it is the same reason Fortinet strips more features from 2 GB models on 7.6.3 and later.

What to do, in order:

1. Move all inspection to flow based. Proxy inspection pulls in WAD and scanunitd, the heaviest memory users, and scanunitd is precisely what conserve mode is killing here. Set your policies to flow inspection and use flow based AV, IPS and web filter profiles. On a lightly loaded 2 GB 40F this single change usually stops the conserve events.
2. Turn off sFlow if you are not actually consuming it. The daily sflowd kills show it is enabled. Remove it under config system sflow and the per interface samplers. If you do use sFlow, flag the daily recycling to TAC as a possible leak, but on a 2 GB box I would simply drop it.
3. Trim features you do not use. voipd is in the cull list, so if you have no SIP or VoIP inspection, remove that profile. Same idea for explicit proxy and anything proxy based you are not relying on. Every proxy feature you disable returns headroom.
4. Catch the growth curve. The monitoring script that was shared is the right tool, run it in memory only mode (option 4,0). It auto collects the correct diagnostics the moment memory climbs, including hardware sysinfo memory, shm and slab, ips memory status and session by memory, so you can see whether one daemon is leaking or it is just baseline footprint. That is the data TAC needs.
5. Do not just raise the conserve thresholds. The memory-use-threshold settings exist, but raising the red threshold on a 2 GB box only masks the problem and risks a hard out of memory. Reduce consumption instead.

The honest bottom line: a 2 GB 40F on 7.4 with full proxy UTM is at the edge of its memory budget by design. With flow mode and sFlow off, a box as lightly loaded as yours should stay out of conserve. If the site truly needs full proxy inspection and flow mode is not acceptable, the 40F is undersized for this firmware and the durable fix is a model with more RAM.