Linux is a two-edged sword. On the one hand, there’s so much you can configure. On the other hand, there’s so much you can configure. It is sometimes hard to know just what you should do to get the best performance, especially on a small platform like the Raspberry Pi. [Hayden James] has a suggestion: enable ZRAM and tweak the kernel to match.
Although the post focuses on the Raspberry Pi 4, it applies to any Linux system that has limited memory including older Pi boards. The idea is to use a portion of main memory as a swap file. At first, that might seem like a waste since you could use that memory to, you know, actually run programs. However, the swap devices are compressed, so you get more swap space and transfers from these compressed swap devices and main memory are lightning-fast compared to a hard drive or solid state disk drive.
In addition to turning on the RAM-based swap, it is important to tune the kernel to make more use of swap now that it is relatively fast. The suggested settings change the following system parameters:
vm.vfs_cache_pressure– Increase the frequency of clearing file caches to free more memory.vm.swappiness– Make the kernel more likely to use swap. Note that the ZRAM swap will have a higher priority than slower swap files.vm.dirty_background_ratio– Allow a specified amount of memory pages to be dirty before writing to swap.vm.dirty_ratio– Absolute limit on dirty pages before I/O starts blocking until the dirty pages are written out.
Of course, these parameters may or may not do the best thing for your setup, so you might want to experiment a bit. Look inside /proc/vmstat if you want to learn more about how many dirty pages you have, among other things.
That’s the nice thing about Linux. You can change things, see what’s happening, and change them again if you like. If you want more insight into your system’s operation with htop, you’ll want to read up on that program. This kind of technique is just the thing for those tiny Linux systems.
I used zram in the Docker contest to run as many containers as possible on a Pi.
I guess Armbian has Zram activated by default:
https://forum.armbian.com/topic/12526-zram-swap-where-is-my-memory/
Why not use zswap? seems more user friendly to me…
But how does the performance compare?
This article explains when to use ZRAM, ZSWAP, and ZCACHE.
https://askubuntu.com/questions/471912/zram-vs-zswap-vs-zcache-ultimate-guide-when-to-use-which-one
Thanks for sharing. As you mentioned this won’t help in every scenario. It give us all a chance to test and tweak on our own. For those of us who are indeed running low on memory and using SD card swap… it will most likely make a noticeable improvement. For example, this solved my Zabbix on Raspberry Pi swap i/o performance lockups. Happy hacking!
there are no files at github for zram.
It’s been part of the linux kernel since 2014 so that might be why. The packages you can download just add config to turn on the feature.
Since when i Zram new?
this is very old and been possible for a long long time.
I didn’t see where in the article Al referred to it as new.
But it certainly is a new concept to me.
Thanks–trying this out on my desktop Ubuntu machine, where there’s a `zram-config` package that sets up zram swap partitions for 50% of RAM, 1 slice per processor. Pretty gnar-gnar so far. Take that, Chromium!
I’m the author of the `zram-swap` script mentioned in the blog post. I wound up writing my own because I couldn’t find a replacement for `zram-config` that met all of my wants: simple design, graceful failure handling and some form of simple user-facing configuration.
The `zram-config` Ubuntu package is pretty dated; It does work, but not quite as advertised. The scripting is brittle and the multiple devices thing is needlessly complicated. A lot of what the script does manually can be simplified away because the same functionality is now baked into zram itself or a function of the zramctl management tool.
Some context: You haven’t needed to allocate individual zram devices per core since Linux 3.14 – the kernel automatically multithreads compression/decompression as of Linux 3.15 – so there’s absolutely no benefit to multiple devices. Manually allocating multiple devices just adds more places where the script can fail during setup or teardown. Speaking of failure if the script does fail for some reason it just breaks and leaves dangling half-configured zram devices that require manual cleanup. This doesn’t happen often, but it does happen.
`zram-config` also makes a significant error calculating memory usage: where the package claims “allocates 50% of ram as zram swap” what it’s really doing is allocating a zram device whose uncompressed (virtual) size is equal to half of physical ram. This is then compressed and occupies ~1/3 to 1/2 of that size in real memory (ie: 1/6 to 1/4 of total installed RAM) when filled. This probably isn’t what most people expect or want after reading the documentation.
If you like `zram-config` take my zram-swap script for a spin, it solves the same problem in a slightly more robust way and without the gripes mentioned above. The script is here: https://github.com/foundObjects/zram-swap — if you do take it for a spin make sure you stop and disable `zram-config` before switching, the two scripts won’t play nicely together.
You should probably post this in the original post as well: https://haydenjames.io/raspberry-pi-performance-add-zram-kernel-parameters/
There’s also a post in Reddit /r/raspberry_pi where the user complains about your script lacking of handling multiple cores.
Thanks for your work.
Could somebody explain the rationale behind this?
Wouldn’t creating these ram-disks (as I understood this does) take away valuable RAM from the system? Swap’s point was to offload memory somewhere to free it for something else.
Swap to disk says “if i wind up overcommitted on ram, give me 100x penalty but let me live” and you can live a long long time, if you give enough swap. Zswap says “here’s a lot less size, but the cost penalty is more like 2x” and it turns out for a lot of systems which only occasionally peak into Swap, and can tend to manage that, it’s better to incur a 2x penalty to a 100x penalty
Numbers may be off, the principle holds. Yes, memory is valuable. So is speed.
Similarly, back when the 386 came out, CPUs were getting so fast but most HDD’s were still in the PIO or early DMA era and thus dog slow. Installing Stacker/Drvspace could actually speed up disk I/O despite the heavy CPU implications, because it meant less total data had to trickle on and off the disk.
Ahh drvspace – that was RLL wasn’t it?
Could this be a way to have the performance of a 4 Gig RAM board from a 2 Gig?
Tl. Dr. No, you can’t execute compressed code and compression takes time.
Depending on what you compress you get different compression ratios. Text can get close to 50% (of original size) while binary data/executables usually is less compressible. (you can test this by using zip since it is based on the same compression that Zram probably use)
Since you can’t execute compressed code the maximum size of the program you can execute is ram minus operating system parts.
Since ram was/is at a premium, your program can page out data to disk while it is not used and page it back in when it is needed. Databases is one way of doing this.
Zram can make it possible for your pi to run more, not lager, programs than space in ram by compressing the ones not in use at the moment.
Also this can lower the wear on the sdcard, but I am just guy guessing here.