05 Oct 2026 · memory · 2 min
zram on a 5.8 GB server: what the measurement showed
The machine has 5.8 GB of memory and runs a deployment panel, a database, a reverse proxy, internal services and development tools. The whole set does not fit in memory, and swap lives on a compressed device (zram), which stores rarely used pages at a fraction of their size.
State before the test
pages in zram ....... 3.7 GiB
compressed .......... 780 MiB, taking 835 MiB of RAM (4.8:1)
available RAM ....... 1.1 GiB
pressure (PSI full) . avg10 0.4%, no relevant stalling
Those 3.7 GiB of swap cost 835 MiB of real memory. Without them, the same pages would have to fit in 5.8 GB, and they would not.
Method
I compared two values of vm.swappiness, the setting that defines the preference between compressing anonymous memory and dropping cache. The load was identical in both runs: allocate 1 GB of anonymous memory in 128 MB steps, hold it for 45 seconds, release it. Two runs per value, to separate normal variation from effect.
What separates the two cases is not how much swap is used, but which kind of page the kernel discards when memory runs short.
| metric | swappiness 150 | swappiness 60 |
|---|---|---|
| anonymous : file reclaimed | 3.1 : 1 | 1 : 32 |
| cache during the load | 545 to 660 MB | 208 down to 73 MB |
| available memory | around 500 MB | 0 MB |
| stall (PSI full) | 3.4 to 5.4 ms | 8.7 to 35.8 ms |
| swap returned on release | around 780 MB | nothing |
Result
With swappiness 60, the kernel dropped disk cache instead of compressing rarely used pages. Cache fell from 208 MB to 73 MB during the load, stalling went from about 4 ms to as much as 35 ms, and the swap was not returned at the end. Available memory reached zero.
With swappiness 150, the same peak cost between 3.4 ms and 5.4 ms of stalling, cache stayed between 545 MB and 660 MB, and around 780 MB came back to memory once the load finished.
Conclusion
On this server, swappiness 150 reduces stalling and preserves cache. The value 60 returned no memory: it traded compression of rarely used pages for cache loss.
The setting was not the cause of the machine’s memory problem. The load came from development processes running on the same server, and that was fixed separately.