[Software] How to know if my swap partition is big enough?

[Enigma83]

I have a Dell XPS 13 9360, which has 16GB RAM. It is soldered to the board and not replaceable or upgradable. I knew this when I bought it and was OK for that, it seemed good enough for my daily needs.

So far, Debian Bookworm runs perfectly on it, I haven't found any glaring nonfunctionality. As good or better than Windows. My experience with other distros on it is about the same.

However, on my most recent install, I have observed several system hangs or program crashes. It happened a few times when my Android devices were connected. Also when I was running a program GUI that relied on Java. And most recently, running Virt Manager VMs have suddenly exited silently.

My swap partition is currently 4GB. I don't use hibernate or suspend, so I figured it would be enough. But now I can't be sure.

I'm aware of zram and zswap, but there's so much conflicting info about them, I'm not sure which to try, if either. There seems to be no general consensus in the Linux communities of one being better than the other. Oftentimes the people advocating either will make a statement but give no backing evidence.

Maybe my CPU is getting overloaded too, but I think this is more of a swap issue than anything else. Linux's memory killer in play, taking down whatever it takes is using too much memory.

[ftb]

Meiner Meinung nach müssten die 16GB Ram + 4 GB swap ausreichen. Die Störungen kommen meiner Meinung nach wo anders her.
Deepl Tranlate
In my opinion, the 16GB Ram + 4 GB swap should be sufficient. In my opinion, the faults come from somewhere else.

[Enigma83]

In my opinion, the 16GB Ram + 4 GB swap should be sufficient. In my opinion, the faults come from somewhere else.

Maybe, but when I had a 16gb swap partition, I can't recall any freezes/program crashes then. It all started happening after I resized it to 4gb. 16gb seemed too much, and still does.

[wizard10000]

The correct amount of swap depends on the machine and how it's used. My own observations, though -

I know you said you don't hibernate but just for reference modern kernels compress the hibernation image; the default target size is 2/5 of installed RAM although this is completely dependent on how compressible the data in RAM might be. If someone intends to enable hibernation I generally recommend swap = RAM because disk space is cheap.

In other cases you just shouldn't run out of swap and again, disk space is cheap and it doesn't sound like 4GB is quite enough for your use case. I think in your case it might be wise to find out how much swap is actually being used in normal operation (you can use swapon -s as root to find out how much swap you're currently using), add a 50% buffer to that and call it good.

Debian's documentation on zram is pretty easy to understand - https://wiki.debian.org/ZRam

Good luck -

[Enigma83]

The correct amount of swap depends on the machine and how it's used. My own observations, though -

I know you said you don't hibernate but just for reference modern kernels compress the hibernation image; the default target size is 2/5 of installed RAM although this is completely dependent on how compressible the data in RAM might be. If someone intends to enable hibernation I generally recommend swap = RAM because disk space is cheap.

In other cases you just shouldn't run out of swap and again, disk space is cheap and it doesn't sound like 4GB is quite enough for your use case. I think in your case it might be wise to find out how much swap is actually being used in normal operation (you can use swapon -s as root to find out how much swap you're currently using), add a 50% buffer to that and call it good.

Debian's documentation on zram is pretty easy to understand - https://wiki.debian.org/ZRam

Good luck -

The main reason I dont bother with hibernation is because it's been iffy for me. I've tried it a handful of times over the yrs (in Windows), usually some quirk would pop up, that went away with it off. So I've come to just only use normal reboot/poweroff/poweron, only keeping my PCs on when I'm using them, or running some whatever (downloads etc) that necessitates keeping it on.

I havent bothered trying either zram or zswap, mainly because there seems to be no clear winner. Surely one may be better than the other, but it probably depends on personalized usage scenarios. And not not knowing which is better to choose for how I use my PCs.

I suppose I could just resize my swap partition to 16GB and call it a day. I'm single booting Debian on a Samsung 980 1TB NVMe SSD that I bought discounted from Amazon. Currently, the biggest partition on it is my home partition, of which I generally use no more than 20-25% during normal usage. The root partition is 100GB, and I've come nowhere close to using most of it. For less important stuff I put it on external drives.

I tried the swapon -s and swapon --show commands, as well as "free -m". With just 1 VM running (Windows 11), I've simulated a high RAM usage scenario with TestLimit from Sysinternals Suite, directing it to use over 90% of the RAM allocated to the VM. After doing that, "free -m" shows that my memory is practically used up completely, but also shows that only one eighth of the swap is being used. TestLimit doesnt release the RAM until you terminate the process, so it's useful for keeping the memory usage at a specified level. Which in turn will decrease the host memory/swap.

Currently that VM has 12GB RAM allocated to it. So that's 75% of the host RAM already used up, assuming the guest is actually using up nearly all memory allocated to it. During this time the host remained responsive. I could probably start a 2nd Linux VM and do something to make it use all of its' RAM allocation. But since each VM has 12GB allocated to it, that would surely exhaust the host RAM and all of the 4GB swap.

Runnging "tail /dev/zero" in a terminal (Debian, not Linux guest VM), quickly results in the OOM killer terminating the process after about 5-10 seconds, which gives me little time to run other commands to diagnose. That's not long enough to check swap usage.

[wizard10000]

From what you mention it doesn't appear that swap is the issue. vm_swappiness is at the default value, yes?

[Enigma83]

From what you mention it doesn't appear that swap is the issue. vm_swappiness is at the default value, yes?

Not sure. Or even how to check it. I'll look into it a bit later today.

[wizard10000]

Not sure. Or even how to check it. I'll look into it a bit later today.

I wouldn't bother. The setting is in /etc/sysctl.conf and if you'd changed it from the default you'd probably know it

If you want to take a look there shouldn't be a reference to vm_swappiness in that file.

[Enigma83]

Not sure. Or even how to check it. I'll look into it a bit later today.

I wouldn't bother. The setting is in /etc/sysctl.conf and if you'd changed it from the default you'd probably know it

If you want to take a look there shouldn't be a reference to vm_swappiness in that file.

I've never changed any swappiness settings. So it's at whatever default value Debian uses. But what makes you think swap isn't the issue? VMs silently aborting don't just happen for no reason. It hasn't happened too frequently, only under very heavy resource usage. I know when this happens because things get visibly slower and sluggish. The most recent time this happened is when both VMs were running at the same time. Normally I can get away with this if either isn't doing something demanding. But in that case one VM exited while the other remained running.

[wizard10000]

...what makes you think swap isn't the issue?

Because so far RAM is maxed out but swap isn't.

[sunrat]

Code: Select all

cat /proc/sys/vm/swappiness

default is 60. There is much conflicting advice on the internet about the benefits or disadvantages of changing it. Generally the default is sane.
You can't really know if your swap is too small without monitoring it. Do that first before anything else.

[wizard10000]

...There is much conflicting advice on the internet about the benefits or disadvantages of changing it. Generally the default is sane.

Yep, I'd set vm_swappiness at 10 for years and a couple months ago began to question whether the default 60 would meet my needs. I ended up removing that particular customization from all four machines and they all still seem to be happy

[CwF]

It is not a goal to utilize Swap. Testing suite software is useful for testing hardware stability, not usage pattern.

The virtualization software isn't mentioned, or I missed it. If VB I should stop typing, if Libvirt I'll continue. Windows sucks up and allocates all memory given, a Linux guest is smart enough to communicate and allocate only actual usage - So give Windows vm's only the allocation necessary to do the job (and its own swap) - leave running only while actually doing that job.

Memory Ballooning does work well under libvirt. I can't remember if it works well for windows guest but there has been a driver for it, for W11 I don't know. For Linux guest it is effective. You'd start a linux guest with a 'current' allocation smaller than 'maximum' then the vm will stall (freeze) before effecting the host and if memory is made available we can dynamically allocate a bit more to the vm and it will magically come to life - clear the situation and then deallocate that additional ram.

On a modern system we want zram, with or without additional traditional swap space. Install systemd-zram-generator or zram-tools, either should get the same result. There are many reasons why swap is used, over allocation is only one reason and in my opinion user-error. Zram will take care of all the 'legit' swap needs and ideally under 'sane' usage is the only form of swap we really need. As sunrat suggest, leave swappiness alone and with zram it should be default to allow zram to do its job.

With 16GB we should be able to run a handful of Linux vm's, each consuming within a gig premium over actual vm usage, each constrained via ballooning with 'current' within actually available, and 'maximum' over-allocation actively user managed.

[wizard10000]

...Zram will take care of all the 'legit' swap needs and ideally under 'sane' usage is the only form of swap we really need.

I'm not quite there yet

I've used both zswap and zram and systemd-zram-generator was where I landed. Of the four machines here one of them has 8GB RAM and the other three have 16GB, all have 4GB zram plus a 4GB swapfile. I use conky to track swap usage on any machine I'm using and I don't believe I've ever seen any of my machines use more than 3GB of RAM or 2GB of swap even when doing some heavy handbrake stuff. That should tell me I don't need a physical swap device at all, but I just can't make the leap quite yet.

[CwF]

heavy handbrake stuff

I don't want to get into the weeds but I have a handbrake example of how excess swap that does nothing for us most of the time can be a lifesaver. It is an example of an errant application using swap - should we plan for that? I haven't really decided...
Anyway, one of the issues with video streams are invalid timestamps. This is likely an old example where newer editions handle the errors better. Handbrake running in the background, I noticed a delay, heard some fans, saw the load average over 28 and noticed swap was at 46GB! I shut down a few things, waited, and then 'Put down the cocktail'!
With broadcast TV there can be timestamp shifts from patching different feeds, so not really errors. Usually this is only a challenge in an editor and recent ffmpeg rewrites the timestamps. Older avidemux maybe didn't. I put two streams together with an append, and at that juncture handbrake got lost and consumed all that memory plotting a solution that it found and finished.
During Live TV viewing this inconsistency blows up the cache if seek is used. I'll be a little behind viewing and the timer will show seconds or a few minutes, and then it will shift to hours or days behind due to a timestamp shift - if I nudge the seek even a little it would zap to current 00:00:00.00 and dump any cache, usually 10-30 minutes worth. And now we know why I use file based tmpfs cache!

That machine uses zram-tools with 20% of 256GB. Handbrake can have a few things queued to put into h.265, a few streams recording, watching one or more, and still serve up vm's to multiple destinations without breaking a sweat. A normal disk swap likely would have saved me too, just slowly. From that example I conclude zram is as effective as disk swap - the memory usage was maybe 50%, but I didn't take note. But I do repeat that I see swap use with as little as 10% USER memory usage. So never go without.

It is important to grasp that zram allocation does not prevent the memory from being used for other purpose. It is a quota, a 50% or even 100% allocation does not 'use' that memory until it actually swaps something out.

Code: Select all

grep Zswapped /proc/meminfo

[Enigma83]

Code: Select all

cat /proc/sys/vm/swappiness

default is 60. There is much conflicting advice on the internet about the benefits or disadvantages of changing it. Generally the default is sane.
You can't really know if your swap is too small without monitoring it. Do that first before anything else.

You were right, the value is 60. I'd rather not go trying to change that value, I'll just have to trust that the Debian devs set it to a sane default. Better not to drive a nail in with a sledgehammer when a claw hammer is better for the job.

[Enigma83]

It is not a goal to utilize Swap. Testing suite software is useful for testing hardware stability, not usage pattern.

The virtualization software isn't mentioned, or I missed it. If VB I should stop typing, if Libvirt I'll continue. Windows sucks up and allocates all memory given, a Linux guest is smart enough to communicate and allocate only actual usage - So give Windows vm's only the allocation necessary to do the job (and its own swap) - leave running only while actually doing that job.

Memory Ballooning does work well under libvirt. I can't remember if it works well for windows guest but there has been a driver for it, for W11 I don't know. For Linux guest it is effective. You'd start a linux guest with a 'current' allocation smaller than 'maximum' then the vm will stall (freeze) before effecting the host and if memory is made available we can dynamically allocate a bit more to the vm and it will magically come to life - clear the situation and then deallocate that additional ram.

On a modern system we want zram, with or without additional traditional swap space. Install systemd-zram-generator or zram-tools, either should get the same result. There are many reasons why swap is used, over allocation is only one reason and in my opinion user-error. Zram will take care of all the 'legit' swap needs and ideally under 'sane' usage is the only form of swap we really need. As sunrat suggest, leave swappiness alone and with zram it should be default to allow zram to do its job.

With 16GB we should be able to run a handful of Linux vm's, each consuming within a gig premium over actual vm usage, each constrained via ballooning with 'current' within actually available, and 'maximum' over-allocation actively user managed.

I've always been of the opinion that swapping is bad, because swap will always be slower than memory. Especially if you're swapping to an HDD backed swap partition/file. The experience is probably better when swapping to SSD, but even the fastest SSDs are still magnitudes slower than RAM. If you're swapping too often, your installed RAM isnt sufficient. You can just increase the swap, but that doesnt really solve the issue. It is always better to upgrade RAM so that you will swap less, instead of increasing swap size. But in my case that isnt an option, so I have to work with either increasing swap or using other solutions to mitigate (zram/swap).

I've also considered that it could be an issue of CPU maxing out. AFAIK Linux doesnt have an "out of CPU" killer that kills processes using too much.

As long as VMs are silently exiting when they shouldnt be, and when they arent under a significant load, there is an isue somewhere. The most likely culprits are either RAM or CPU. They have also exited when both are under stress, but that's to be expected, when your hardware clearly isnt up to snuff and your VM allocated RAM are using more than your installed RAM+swap amount. You dont need a PhD in physics to know that, just a bit of common sense.

The VM solution i use is Virt Manager, (KVM+QEMU+libvirt+Virt Manager GUI for management).

[CwF]

The VM solution i use is Virt Manager, (KVM+QEMU+libvirt+Virt Manager GUI for management).

That be the one. (Say that ten times fast)

[Enigma83]

The VM solution i use is Virt Manager, (KVM+QEMU+libvirt+Virt Manager GUI for management).

That be the one. (Say that ten times fast)

You trying to be funny? If so, I'm quite difficult to humor. But Virt Manager and its' backends are hands down better than VMware/VirtualBox by a mile (or kilometer, in non-US nation that use metric instead of imperial for measurements). I haven't used them ince, there's just no need. Virt Manager gives significantly better performance.

[CwF]

You trying to be funny? If so, I'm quite difficult to humor

Yes, of course.
Text 'is quite difficult to humor'
KVM+QEMU+libvirt+Virt Manager is quite the mouthful. A few post back, after typing out various combinations in various orders for years, I decided to be simple and simply use 'libvirt' to refer to this 'ball of wax'. It is the core for the most part.