I am a happy ZRAM user for several years now. Basically it makes my 4GB netbook totally usable running Gnome and a Browser with a lot of open tabs.
After reading Debunking zswap and zram myths last week, I thought to give ZSWAP a trial, since the machine had a 3 GB swap partition anyway.
I disabled ZRAM, and enabled ZSWAP and configured it to use the defaults with ZSTD.
I would have expected, that my machine would perform as good as with ZRAM, perhaps a little bit slower because of accessing SWAP instead of just using the RAM.
Surprisingly, my machine froze using ZSWAP after opening at most half the amount of tabs in my browser that I would open when using ZRAM. Was the first freeze on this machine I can remember, after I made the switch to ZRAM.
I increased the zswap.max_pool_percent from its default of 20 percent to 50 percent, which improved the situation a little bit, but still the machine froze again.
I saw the the physical swap was being utilized.
I reverted back to ZRAM, where I configure by default the size to be double the amount of RAM, something like 8 GB (!), again with ZSTD. I could open an insane amount of tabs again, I saw that nothing was swapped to the physical swap, everything was in the RAM disk. No trouble, no freezing.
My question is, why do I observe this? Should not ZSWAP with 50 percent of RAM and a physical SWAP partition outperform ZRAM, at least concerning the number of open tabs in the browser? (I could understand a performance loss because of swapping to the SSD.) Why does the out of memory systemd service not trigger properly with ZSWAP?
Using Debian 13 on an Intel Celeron, in case that should be relevant.
Update:
- I understand, that ZRAM is just a compressed RAM disk and that the 8GB I configure is the size of the compressed data on it, not the actual size it takes in memory
- I understand, that ZSWAP is a caching layer in front of regular swap, integrated into the memory manager subsystem of Linux
According to my understanding, this still does not explain, why ZRAM outperforms ZSWAP. The physical RAM consumption of ZRAM with a lot of open tabs is roughly 2GB. ZSWAP should have had roughly 1.9 GB of RAM for compressed pages ) + 2.9 GB of physical swap. If we assume a compression factor of 3 this sould be roughly 1 GB of additional swap compared to ZRAM, which still performs worse. Again, in both cases ZSTD was used.
Update 2: When I write ‘freeze’, I mean full out of memory crash when using ZSWAP. The machine ‘freezes’ fully, inclusive mouse cursor and nothing happens, even if I leave it alone a few minutes. Sorry, English is my 2nd language.
What is the storage medium? If it is inexpensive or really old you are probably overwhelming your disk bandwidth. If it is cheap flash be really careful as it has a limited number of writes.
Freezing can be a sign of a I/o bottleneck
Thank you for the warning!
I am not sure I used ‘freezing’ in the correct way, my machine has a full (I guess) out of memory crash. Since the physical swap runs full, I assume i/o should be ok. Sometimes I also install games from GOG on this machine, which is heavy read/write i/o, so again, I guess that i/o is not the problem here.
In general, ZRAM performs better than ZSWAP on low-memory devices. Google has used ZRAM on Android for a while. Since you have 4 GB of RAM, ZSWAP accesses the physical drive, which makes it feel a little slower than ZRAM.
Using Debian 13 on an Intel Celeron, in case that should be relevant.
I installed a dual boot of Linux Mint and Endeavour OS on my weak mini PC [Celeron 1007U, 8 GB RAM, and 500 GB HDD]. I use ZSWAP on Linux Mint and ZRAM on Endeavour.
While KDE on Endeavour OS uses 700-900 MB of memory after booting, it feels slow before reaching the desktop screen, and the HDD LED constantly blinks. Cinnamon on Linux Mint uses 1 GB of memory after booting, but feels much faster with less HDD LED blinking.
I think the situation is a bit more complex on a Linux desktop than on a Linux server. Depending on your hardware configuration, Linux distro, and DE/WM, the performance of ZSWAP and ZRAM may be affected.
To add to that: Zswap can make sense if you need lots of data in memory and you have very fast storage devices. Outside of that limited use case zram is the right answer like you said
Yeah, seams like it!
Sorry, my English is not good enough.
ZSWAP basically crashed. The computer had no stutters, it stopped working at all. It did not really feel slower with ZSWAP vs. ZRAM.
I used the same computer with exactly the same desktop/browser configuration, so it should be a ‘fair’ comparison between ZSWAP/ZRAM.
I also have to add, I am using ZRAM on high memory devices, too, w/o any trouble. ZRAM should IMHO even perform better, when you have more memory, because the RAM disk can be bigger and hold more data.
As I said, ZRAM performs better on low-memory devices. A device with 4 GB of RAM should be considered low by today’s standards.
On devices with 8 GB of memory or more, you won’t see any difference in performance. In certain cases, ZRAM may be exhausted due to low memory.
I ran into this issue with dBeaver [a java applet database manager], it would crash after a while. Also, compiling from the source code may exhaust ZRAM since there’s no physical swap, just like Chris said, you’ll need OOM killer to avoid these situations.
Sorry, I cannot follow you.
There is no reason at all, to not have physical swap when using ZRAM. My physical swap just has a lower priority and is never used, when using ZRAM.
You claim that there is no performance difference, once you have >= 8 GB of RAM. I would assume it is much relevant what kind of usage is thrown at ZSWAP/ZRAM instead of the size. Perhaps you could elaborate, why, in your opinion one will not observe a difference in performance and why this limit would be exactly 8GB? I also use ZRAM on my 8GB machines, with a physical swap partition as backup and physical swap is never touched.
OOM killer is IMHO independent of ZSWAP/ZRAM, because swap space has an upper limit anyway, and a functioning OOM killer is IMHO preferable to a crashed system. I was just surprised, that the OOM killer did not work for me, when using ZSWAP, because IMHO it should have killed the browser in my example.
Finally, why do you claim that ZRAM performs better on low-memory devices, because I do not see a reason that it should, or that such a generic answer makes sense.
Please understand my intention here: I want to understand WHY you make these statements and what is the technical reasoning behind them.
I have the same experience. I don’t really understand why tbh. I have looked at some of the kernel code but I wasn’t able to understand it.
My experience is that zram has vastly more aggressive compression and can compress way more data. Zram will happily sit there and compress 7 gb of data into 1.5 gb, whereas zswap never hits those numbers.
So I disagree with the common takes about swap being needed with zram. Because zram will compress everything that would otherwise be put into swap, into the same amount of space zswap will use to store a fourth of that data, whereas everything else would be put into swap. And because decompressing is faster than swapping, it leads to a smoother experience.
Thanks a lot for sharing. I am happy, it is not just me.
Fedora uses ZRAM w/o swap by default since a few years AFAIK. ZRAM is to the best of my knowledge also heavily used in Android phones w/o swap and of course Chromebooks w/o swap.
For me, swap is never used when ZRAM is activated, I will probably not setup a partition for new installations of Debian.
I still do not get, why it seems that people like Chris Down are so strong in their recommendation for ZSWAP. Chris seems to work at META and probably sees primary server workloads. But I would expect a developer of his caliber to be able to understand and formulate, where ZRAM beats ZSWAP and the other way around. Even in his article above, he is a little bit more nuanced concerning his recommendations. My personal takeaway for now is, to use ZRAM on desktops unless I really need/want hibernation.
I think the problem is they analyze it by how it appears to work rather than measuring raw numbers. Because honestly, I don’t really understand why zram compresses better either.
Because the interactive diagram on that blogpost below “LRU inversion” is interesting, and it’s a great example of what should happen, but it’s not accurate to my experience. What actually happens, IME, is that 1, 2, 3, 4, 5, 6, , 8, 9, 10, 11, 12 stay in zram forever and never get swapped to disk. Even when I had 8 gb of ram (on the mac mini) I had that experience.
Excellent point! The whole point about ‘LRU inversion’ falls apart, if the data never leaves ZRAM in the first place.
Thank you very much for the links. I already know the information there, I’ll update my question.
Wish I could be more helpful, but I’m not clued up enough on this topic. So, thought I’d share what I could.
