System freezes when running out of memory

My Fedora install freezes completely when I run out of memory. I figured that perhaps I didn’t configure enough swap, but when I looked it used zram. A concept I was not familiar with until now.

Given that I have 16GB ram, I figured I want 32GB swap space. But I’m old school and I don’t know if that rule holds on modern machines and with zram. It looks like zram only has 8GB available. What is the recommended way to expand this? Should I configure zram to use more RAM? Or should I create a separate lower-priority swapfile on disk?

This is better the more memory in zram.

What are you running that uses all the memory?
You may find that performance with swap is terrible.

1 Like

My suggestion:
Add additional ram.

The default config creates zram0 in ram for swap sized at 8G. You said that the system freezes, but IME the system should use the oomd to kill processes that are using excessive memory when the ram is filling up.

Have you experienced any processes that suddenly are killed?

What is showing when using the command free?
That command shows a result similar to this and if ram is actually filling up it should show that.

$ free
               total        used        free      shared  buff/cache   available
Mem:        32778188    15811664     1262960      244980    16439364    16966524
Swap:        8388604        1024     8387580

The “best” solution would be to add more physical RAM. You can increase the zram size, but if you are already using that much RAM it will only alleviate your issue slightly. Adding physical on disk swap may prevent the system freeze, but again, if you are using that much RAM you will spill over to the swap space causing the whole system to respond slower (even if you put the swap on a SSD). You should also figure out what is eating all your RAM.

1 Like

Hi Evert,

(I am older school … LOL)
You could create a swapfile along with the zram (I am not much of zram fan though because I see it as compounding the issue of running of RAM … kind of pointless because swap in zram uses the RAM you are already running out of …)

Ok, rant over …

Generally speaking, when you set up swap it is usually %120 of installed RAM … you do it in Linux/Fedora the same way you used to do it in Unix proper …

  1. create a swap file — mkswap [options] --size size --file file
  2. make an entry in /etc/fstab — /SWAPFILE none swap defaults 0 0
    (mine in the root of an NVME)
  3. swapon -a

Now, this will only really give you time to resolve oom and it will slow things down when swap starts getting used

Best solution is to find out what is eating your RAM and resolve that … install more RAM if you can or decide what you really have to do all at the same time :slight_smile:

There are problems using swapfiles in btrfs.
Much better to create a dedicated partition or you need to manipulate how it is created as a swapfile.

One of the issues is the COW feature of btrfs which means you would be doing a lot of writing and have even more delays with swap.
This is only one of the related posts

Most of the memory usage is going a whole bunch of open Firefox windows. AWS Console and Figma seem especially hungry.

From what I understand one of the things “btrfs mkswap” does is turn on +C attribute that turns off copy-on-write for that file

Thank you! It’s a bit hard to install more ram in this laptop. Maybe it’s time to get a framework and go to 32GB. Swap is on! Hopefully it gives the oom killer more time

I got a bunch of snapshots with top and smem, and it seems that by a long shot Firefox eats the most. I do a lot of context switching in my job. Videos open, heavy webapps, etc. For some reason LinkedIn is the worst while it loads. Amateurs

I honestly have no idea why the OOM killer doesn’t kick in. Nothing interesting in journald either. Anyway solved for now! Added swap with btrfs mkswapfile

Accepting this as the solution, although btrfs mkswapfile is the way to go instead of mkswap.

Zram compresses the pages which frees memory and is very fast.
Freeing memory very fast is important to avoid system stalls research has shown. Disk based paging is too slow and leads to system stalls, even using SSDs.

1 Like

Fair but for me it’s system stalls or complete crashes. Unless you have another suggestion for this!

Note the time of the next stall and then look in the journal logs for time leading up to hang. Do you see any clues as to what is happening?

I’ve kept an eye on things with top, and it’s definitely completely running out of memory when this happens!

You see that “free” and “buff/cache” are very small also that swap “used” is high?

So these are numbers being reported now with the extra 32GB swap:

$ free                                                                                                                                                                                                 
               total        used        free      shared  buff/cache   available
Mem:        16073296    13228544      454268     3903260     6641916     2844752
Swap:       41943032    14349752    27593280

FYI i would use free -h to make the numbers easier to read.

You are paging out data to make everything fit in memory.
But there is a lot of memory used for buff/cache that I take to mean the system is getting work done.

If you get stalls the more memory will help.

If you are curious you can run vmstat to monitor the paging I/O, the si and so rates.if you have a lot of swap used, but low swap I/O then the system will be responsive, but if you have high swap I/O you may see stalls.

Thanks! Yeah already feeling the stalls :melting_face:

But without the freezes at least I can recover and not drop out of calls! Appreciate all the help

I do wonder about your system, since i’m also using a Firefox derivate with a bunch of open tabs and i usually get nowhere near that memory usage. Currently i have about 15 tabs open including including heavy sites like Youtube and Discord, and memory use of the browser is around 2.5GB.

As a suggestion, you could try the Zen browser (flatpak) which is a Firefox based browser that has a built-in option to automatically unload memory used by idle tabs after a designated time. I’m not using that feature myself but it might help in your case where tabs seem to use a lot of memory.