Bottom Line: “ZimaOS Uses More RAM After 1.6” Is Not Specific Enough—Find the Process or Container
The 8 GB system still showed high memory after moving from 1.6.0-beta2 to the stable release. That rules out the easy explanation that it was only beta overhead. The useful next step is attribution: which container, cache or host process owns the memory, and is the system actually under pressure?
Start With Available Memory, Not Just the Dashboard Percentage
free -h
docker stats --no-stream
ps aux --sort=-%mem | head -20
dmesg | grep -i -E 'oom|out of memory'Linux uses otherwise idle RAM for cache. A high “used” number with healthy available memory and no OOM/swap pressure is different from a leak. The Linux memory accounting is the upstream reference.
Container Totals Explain Only Part of the Host
The screenshot shows several containers consuming hundreds of megabytes each, but adding them together does not necessarily equal the whole host total. Docker memory metrics, kernel cache, page cache and non-container services are separate accounting layers. Docker's Docker container stats explains the container view.
Do Not Assume Stable 1.6.0 Included a General Memory-Leak Fix
The current 1.6.0 release notes list storage, Docker-startup, Files and network fixes, but do not document a broad memory-leak fix. So a current diagnosis should remain evidence-based rather than saying “upgrade and it is fixed.”
The ZimaOS 1.6 changes is the current release context.
What Counts as a Real Leak
Watch the same process over several hours. A leak is more plausible when one process grows monotonically, available memory shrinks, swap rises, or the kernel begins killing processes. If memory plateaus and the system stays responsive, it may simply be a larger steady-state working set.
The ZimaOS app requirements helps identify whether the installed app mix is simply too large for an 8 GB host.
