Proxmox 9 – zarządzanie pamięcią RAM i SWAP

Super — z Twoich danych widać dokładnie, co się dzieje, i… to wcale nie wygląda jak “mielenie swapem”, tylko swap zapełniony historycznie + kernel nie widzi potrzeby go opróżniać.

1) Co mówią Twoje liczby (wnioski na chłodno)
ZRAM/SWAP
/dev/zram0  DISKSIZE 8G  DATA 7.8G  COMPR 3.9G  TOTAL 4G
swapon: USED 8G/8G


Swap 8/8G = 100% w GUI (to pokazuje Proxmox).

Ale realnie w RAM to kosztuje ~4G (TOTAL 4G) dzięki kompresji lz4.

Czyli to nie jest “swap na dysk”, tylko skompresowany bufor w RAM.

RAM
Mem total 109Gi
used 77Gi
buff/cache 31Gi
available 32Gi
free 1.5Gi


Najważniejsze: available 32Gi — masz bardzo duży zapas pamięci możliwej do odzyskania (głównie cache).
To znaczy: system nie jest pod presją RAM.

PSI (memory pressure)
some avg10/60/300 = 0.00
full avg10/60/300 = 0.00


To jest mocny sygnał: aktualnie brak presji pamięci.

vmstat (czy teraz swapuje?)

U Ciebie:

pierwsze 1–2 sekundy: si 6–8, so 19 → drobne ruchy

potem: si=0 so=0

Czyli: nie mieli swapem cały czas. Swap jest pełny, bo kiedyś tam strony zostały przeniesione do swap, a kernel nie ma powodu ich przywracać “dla sportu”.

2) Dlaczego Linux trzyma 100% swap, mimo że ma RAM?

Bo to jest normalne zachowanie:

kernel wrzucił “zimne” strony do swap, gdy kiedyś uznał to za korzystne,

potem RAM się zwolnił (np. skończył się backup, spadło obciążenie),

ale kernel nie opróżnia swap automatycznie, bo to nie daje mu zysku (po co kopiować dane z powrotem, jeśli nikt ich nie dotyka?).

Jeśli chcesz, żeby zdecydowanie rzadziej robił taki manewr, klucz to swappiness.

3) Najlepsze ustawienie “RAM > zram”: obniż swappiness + page-cluster
Sprawdź aktualne wartości
sysctl vm.swappiness vm.page-cluster vm.vfs_cache_pressure

Ustaw na próbę (od razu)

Polecam startowo:

swappiness=10 (bezpiecznie i bardzo sensownie)

page-cluster=0 (mniej hurtowego swapowania; zram to lubi)

sysctl -w vm.swappiness=10
sysctl -w vm.page-cluster=0


Opcjonalnie (często dobrze działa na hostach z VM):

sysctl -w vm.vfs_cache_pressure=50

Ustaw na stałe
nano /etc/sysctl.d/99-ram-over-zram.conf


Wklej:

vm.swappiness = 10
vm.page-cluster = 0
vm.vfs_cache_pressure = 50


Zastosuj:

sysctl --system


Efekt oczekiwany: po tej zmianie system będzie dużo mniej skłonny wypychać anon pages do swap (zram), dopóki ma sensowny “available”.

4) Jak zbić 100% w GUI natychmiast (opróżnić zram swap)

U Ciebie jest to bezpieczne, bo masz MemAvailable ~32GiB, a swap trzyma “DATA 7.8G” (czyli tyle trzeba wciągnąć do RAM — w praktyce cache się skurczy i wejdzie).

Wykonaj:

swapoff /dev/zram0
swapon /dev/zram0


Po tym:

swapon --show powinno pokazać USED ~0

Proxmox GUI przestanie pokazywać 100% swap

(i dopiero wtedy Twoje nowe swappiness zdecyduje, czy swap znowu będzie się zapełniał)

Ważne: zrób to, gdy host nie jest pod ciężkim I/O/CPU (to operacja “przerzucania” stron, może chwilowo podnieść latency).

5) Jeśli chcesz sprawdzić “kto” trzyma swap (top procesy po VmSwap)

Szybki one-liner:

for p in /proc/[0-9]*; do
  pid=${p##*/}
  swap=$(awk '/VmSwap/ {print $2}' $p/status 2>/dev/null)
  [ -n "$swap" ] && [ "$swap" -gt 0 ] && \
    printf "%10s KB  PID=%s  %s\n" "$swap" "$pid" "$(tr -d '\0' < $p/cmdline | cut -c1-120)"
done | sort -nr | head -20


Na Proxmox często na górze będą:

kvm/qemu-system-x86_64 (VM-ki),

czasem duże usługi (DB, monitoring, itp.).

To nie zawsze znaczy “problem”, ale daje jasność.