Best way to setup swap partition?

[Dunuin]

Uptime of 7+ years of migrated vm's or pve nodes itself ? But anyway that's good luck with hw and prepared environment.
If that are node years you could be sure not running on same time further ...

Node uptime. See some peoples posts asking for support:

Here for example 1264 days of node uptime running kernel 4.13 in 2023
https://forum.proxmox.com/threads/permission-denied-error-for-vzdump-command.130885/#post-574612

 

[leesteken]

Here for example 1264 days of node uptime running kernel 4.13 in 2023

How do you mitigate Proxmox/kernel security issues and QEMU attacks from inside VMs and containers, which have come to light is the last 1264 days?

 

[Dunuin]

You don't. I just hope most people are running those servers air-gapped and not to host some webservers. But probably it's more like a case of "never change a running system".

 

[waltar]

Yup, and never run a changing system ...

 

[esi_y]

I just hope most people are running those servers air-gapped and not to host some webservers.

Have you ever tried searching 8006 with pve-api-daemon as Server on Shodan?

 

[LnxBil]

Do you inter-mix them or are you settled on one over the other? I looked at some of the debates on them and it seems there's no clear winner.

First level is always zram. On some machines, I have an additional layer of disk swap, yet mostly on the hypervisor itself, where more swap could be needed.

One problem might be missing RAM defragmentation when you never swap out data from RAM to disk and later back but reordered/compacted. You might end up with "free" RAM that can't be used because it is too fragmented and then OOM killer kicks in while still having lots of free RAM left that can't be used.

Exactly. You'll see this in the OOM message and it's all based on the slab allocator and is exposed in /proc/buddyinfo if you want to learn more about it. Dropping caches and compacting as you already said can clean it up, yet has of course performance side effects.

Having hugepages and normal pages stresses the system even more in terms of unusable memory if you have free space in of them, yet not in the other. Hugepages are not swappable (at least was this case for the last 20+ years ...)

 

[esi_y]

Exactly. You'll see this in the OOM message and it's all based on the slab allocator and is exposed in /proc/buddyinfo if you want to learn more about it. Dropping caches and compacting as you already said can clean it up, yet has of course performance side effects.

Having hugepages and normal pages stresses the system even more in terms of unusable memory if you have free space in of them, yet not in the other. Hugepages are not swappable (at least was this case for the last 20+ years ...)

So everyone just sets swappiness to their desired value and creates SWAP, nobody uses cgroups params and let the OOM do its job?
https://www.kernel.org/doc/html/latest/admin-guide/cgroup-v2.html#memory-interface-files