[solved] Disable swap - Good or bad idea ?

[MorgothSauron]

Hello,
I know there is no one size fits all solution when swap is involved. However I'd like to check few things with you.

I have 16Gb of RAM and a 1.5Gb swap file. With this setup I'm pretty sure to have a system freeze when under heavy load. By freeze I mean that the GUI (KDE) is unresponsive, music repeating on a 2 second loop and I'm unable to switch to a console (ctrl+alt+f1). All I can do is a hard reset and damn I hate doing that.

This morning I made a mistake that triggered a system freeze again. I had a 4Gb virtual machine running while portage was building Firefox. The system became completely unresponsive. I know, I should have expected that to happen.

I know that the swap file may have a role to play here, but why didn't the kernel kill memory intensive process (oom kill) to "save" the system from this situation ? Killing the qemu process would have saved me a hard reset for sure.

Right now I'm debating over 2 options:

- Disable swap completely
- Reduce the size of the swap file

What do you think ? What would be the best option for me to prevent those system freeze ? I know that a freeze might still happen, but at least have the OOM Kill to happen.

[Perfect Gentleman]

There is 3rd option:
- disable swapfile and enable swap on ZRAM

[Ionen]

Are you sure it's due to swapping? Have you tried to ssh from another machine if possible? You may be able to get some more info from dmesg.

If you were using nvidia-drivers 455+ I'd have a decent guess at what might be happening given it happens during heavy I/O / ram usage and ssh should still work, not that every setups is affected.

[MorgothSauron]

[MorgothSauron]

[Ionen]

I see, nevermind then.

For zram we do have a wiki page: https://wiki.gentoo.org/wiki/Zram

I think it's great on low memory systems, but with 16GB I'd try to manage ram usage better instead. But if you really need more without adding more physical ram, then ram does compress pretty well.

I personally try to just not build firefox when I run my VMs Shouldn't happen unless some unlikely timing but I'd hate the idea of risking the VM being killed from OOM too (I don't care if rustc/cc1plus gets killed though). I'm sure there's ways to control this but never really looked into it.

[trilithium]

The best option is to get enough RAM to run the software you want.

I invested in a generous amount of RAM and disable both swap and overcommit. I see no way to have a reliable system while never letting memory allocations fail and killing large processes according to some heuristic when physical memory runs out. Software that relies on overcommit or can't deal with memory allocation failure in a reasonable manner needs to be fixed or replaced.

[MorgothSauron]

I know that this morning it was my fault. A 4Gb VM and a Firefox build at the same time was just asking for troubles. I don't usually do that kind of stupid thing, but it happened today.

I'm just looking for an alternate swap or no swap config that could alleviate system freeze when under heavy load.

[MorgothSauron]

[Perfect Gentleman]

[Ionen]

1.5GB swap doesn't really amount to much vs 16GB either way, might as well not be there if it's causing problems.

Personally my system stays responsive during heavy swapping though, at most I'll get some crackling audio but keeps working -- so I like having some decent amount in case (and almost never in use due to vm.swappiness = 1). I do have the swapfile on a nvme ssd though, so I guess that's related.

[MorgothSauron]

[MorgothSauron]

[Ionen]

I meant that it's easy to go outdo that 1.5GB and start doing OOM kills. I do wonder why your system freezes so badly though Not that I'm overly familiar with how swap gets handled.

[MorgothSauron]

[Ionen]

What I/O scheduler are you using? Not [none], right? If all rootfs i/o came to a halt due to swapping I guess it could be something that'd freeze the system pretty well.

Edit: I know some people sometime recommended [none] for nvme ssd like it was immune from being 100% used

[NeddySeagoon]

MorgothSauron,

Disabling swap is a bad idea. The kernel has several ways it can swap and disabling swap prevents one of them from working and puts pressure on the others.

Swap, file/partition/zram, no matter how its implemented, is only used for dynamically allocated RAM. That includes the content of tmpfs.
Think of it as RAM content that has no permanent home on disk.

The kernel will (eventually) use all of RAM for disk buffers, ether read buffers or write buffers. Buffers are not dropped until the RAM is needed for other things.
Dropping read buffers is instant. The data is already on disk and can be reread as required.
Dropping dirty write buffers takes a little longer. They must be flushed to disk first. They are never written to swap. That's the wrong place.

Now it gets worse.
Your executing program code is like a read buffer. It can be dropped instantly and reloaded as required. That's a very bad thing if it happens.
Code executes at less than the speed of disk reads.
The program goes for some code, gets a page fault because its not in RAM, the kernel does a context switch to try to let something else run while it fetches the missing code and so on.

swap can delay the onset of 'code swapping' when RAM is marginal, maybe prevent it by providing a home for dynamically allocated RAM that won't be needed for a long time.
_________________
Regards,

NeddySeagoon

Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail.

[MorgothSauron]

[Ionen]

I think that may be the related to your freezing issues then, I use [bfq] myself (with its default low latency mode, nice for a desktop).

With [none] if I were to use the i/o 100% of my nvme ssd then I can't even open a man page anymore until that's done. Applications of course wouldn't be able to read libraries, config files, or any other filesystem access and hang trying to read stuff.

If I do the same with [bfq], then the man page opens like it's nobody's business.

[389292]

option 4:
lowering the makeopts

[MorgothSauron]

[Ionen]

There's differing opinions on best practices regarding this, and indeed not really a one-size-fits-all.

But I do believe your freezing is really just a scheduler issue, you have the swapfile on your nvme ssd (which I guess is your rootfs / ). And when heavy usage kicks in it doesn't let anything else work with a noop [none] ""scheduler"". If can resolve this then "occasional" swap usage wouldn't be so bad.

[Anon-E-moose]

[MorgothSauron]

[MorgothSauron]