SWAP läuft voll obwohl mehr als genug RAM da ist

[whiterabbit]

Hallo.
Das topic sagt im Grunde schon alles:
Ich habe einen Server mit 128 GB RAM, von dem die Systemübersicht zeigt,dass gerade mal
30.99 GiB von 125.88 GiB belegt sind. Dennoch läuft mir die SWAP-Datei voll: 100% (12 GB groß).

Wenn ich "vmstat 1" aufrufe, erhalte ich

procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
 1  1 12582908 740364 142988 100881024    0    1   580   173    1    1  3  1 96  1  0
 1  1 12582908 742992 142988 100881152    0    0     0     4 10182 17011  3  0 94  3  0
 1  1 12582908 745580 142988 100881152    0    0     0    36 10724 17611  3  0 97  0  0
 1  1 12582908 748144 142996 100881144    0    0     0    88 9818 17247  3  0 97  0  0
 2  1 12582908 751140 143004 100881152    0    0     0    84 10630 17853  3  0 96  1  0
....

In der GUI steht mittlerweile:
SWAP-Auslastung 100.00% (12.00 GiB von 12.00 GiB)
Hat einer eine Idee, was da schief läuft?
Allen VMs zusammen habe ich RAM in Höhe von 89 GB zugeordnet. Es müsste also noch mehr als genug für's System da sein!??

 

[whiterabbit]

Scheint gelöst zu sein... swap war defekt. swap neu erzeugt und Neustart. Zudem swappiness auf 10 gesetzt ... erstmal Ruhe.

 

[fireon]

swappiness auf 10 gesetzt

Seit wann geht das denn wieder? Ist ja seit 5.0 defekt.

 

[whiterabbit]

Hi. Weiß nicht -- ich habe es mit dem Befehl
"sysctl -w vm.swappiness=10" versucht, der ohne zu meckern angenommen wurde.
Quelle: https://pve.proxmox.com/wiki/ZFS_on_Linux (ganz unten)

Habe jetzt (seit gestern Abend) nur noch diese Auslastung:
SWAP-Auslastung 2.47% (504.93 MiB von 20.00 GiB)
Das sieht schon ganz anders aus...

 

[fireon]

Hm, ok. Ja der Befehl geht immer. Nur der Wert selbst war nichtig. War bis jetzt trotz 10 oder 0 oder 1 immer auf 60. Tja, vielleicht wurde es ja schon gefixt.

 

[scaa]

Hat sich irgendwas verändert seit V5? Wir hatten neulich einen Host von V4 auf V5 geupdated und seitdem gibt es massiv Probleme mit der Performance, was offenbar mit dem Swap zusammenhängt.
Auf dem Host läuft nur eine einzige VM mit 3 TB Größe. Dieser VM wurde 30 GB zugeordnet. Der Host hat insgesamt 32 GB RAM.
Auf dem Host gibt es eine 40 GB große Swap-Partition.

Mit Proxmox V4 lief alles immer perfekt. Seitdem auf V5 geupdated wurde geht bei den regelmäßigen Imagebackups (LZO (schnell ) / Modus= Snapshot) das Hostsystem in die Knie. Der Swap wird immer stärker genutzt und die VM reagiert nur noch sehr träge.
Erst wenn ich mit "swapoff -a" auf dem Host die Swap-Nutzung langsam wieder reduziere, beruhigt sich alles wieder - bis zum nächsten Backup.

swappiness stand vorher beim Host und der VM immer auf Default (60). Habe es nun mit 0 und 1 versucht, aber am Verhalten ändert sich nichts.
Ich weiss 40 GB Swap sind eigentlich zu viel, aber das Verhalten des System war mit Proxmox V4 vollkommem OK, nichts auffälliges. Mit V5 leider nicht mehr... Also muss doch irgendwas anders laufen seit V5.

Kurz zur Hardware:
Es arbeiten 4x 2 TB SAS-Laufwerke im Raid 10 und 2x 2 TB SAS im Raid-1 als Backupstorage. Verwaltet über ein 3ware 9750SA-8I.

 

[fireon]

Deswegen haben wir den Swap abgeschaltet. Macht seit 5.x Probleme. Bei ZFS arbeiten wir seitdem mit ZRAM.

 

[scaa]

Leider kein befriedigender Zustand. Für uns ist das aktuell der Grund warum wir viele andere Hosts aktuell noch nicht updaten.

 

[whiterabbit]

Deswegen haben wir den Swap abgeschaltet. Macht seit 5.x Probleme. Bei ZFS arbeiten wir seitdem mit ZRAM.

Gibt es dazu eine Anleitung?
Ich bin nach 9 Tagen Uptime und täglichen Backups schon wieder bei 13 von 20 GB angekommen ... und ich fürchte, dass es weiter hoch geht.

 

[scaa]

Also den Swap kannst Du ganz einfach in der fstab auskommentieren und neu booten.

Allerdings bin ich mehr an einer Lösung MIT Swap interessiert. Es muss ja einen Grund geben, warum V5 hier anderes agiert als die alten Proxmox-Versionen

 

[whiterabbit]

Ja, das ist klar -- aber mir ging dabei eher um den Teil "Bei ZFS arbeiten wir seitdem mit ZRAM."
An einer Lösung MIT Swap wäre ich allerdings dennoch auch interessiert ...

 

[fireon]

Zram haben wir auf unserem Repo: https://apt.iteas.at/

apt install zram-config
systemctl start zram-config.service

Swap als 2te Instanz belassen oder deaktivieren.

sync ; sync ; sync ; swapoff -a

Dann nicht vergessen in der FSTAB zu deaktivieren. Der SWAP was dann angezeigt wird ist dann in Wirklichkeit komprimierter Ram.

 

[julio12345]

bei mir immer in Top 2 Verbraucher sind: pvedaemon und pve-firewall
Wie sieht es bei Euch aus?

(echo "COMM PID SWAP"; for file in /proc/*/status ; do awk '/^Pid|VmSwap|Name/{printf $2 " " $3}END{ print ""}' $file; done | grep kB | grep -wv "0 kB" | sort -k 3 -n -r) | column -t

COMM PID SWAP
pvedaemon 28965 42376 kB
pve-firewall 28927 39848 kB
kvm 3163 39736 kB
pvedaemon worke28970 38020 kB
pvedaemon worke28969 37896 kB

 

[whiterabbit]

Bei mir sieht das so aus:

COMM             PID          SWAP
kvm              6649         7263120  kB
kvm              9801         6667076  kB
kvm              30317        2009444  kB
kvm              7911         1606724  kB
kvm              16293        1603508  kB
kvm              26565        782676   kB
kvm              9670         768224   kB
kvm              7569         546584   kB
kvm              7721         422428   kB
kvm              7337         352268   kB
pvedaemon        6526         102084   kB
pvedaemon        worke39879   77816    kB
pvedaemon        worke14873   73656    kB
pvedaemon        worke40192   71444    kB
pve-ha-crm       3752         61040    kB
pve-ha-lrm       3477         43532    kB
pvestatd         6511         42548    kB
pve-firewall     6501         39088    kB
pveproxy         6573         12988    kB
pveproxy         worker35067  11616    kB
pveproxy         worker1288   11608    kB
pveproxy         worker38234  11592    kB
spiceproxy       6603         11196    kB
spiceproxy       work12208    10548    kB
pmxcfs           39533        8984     kB
kvm              19546        852      kB
systemd-journal  646          356      kB
systemd          1            312      kB
(sd-pam)         14306        184      kB