Warum verwendet der Server Swap?

[slu]

Hallo,

hab hier ein KVM Host mit Debian 12 und 768 GB RAM.

Obwohl in der /etc/sysctl.conf vm.swappiness = 1 steht fängt er immer wieder an den swap zu füllen, aber warum?

Code: Alles auswählen

root@kvm:~# free -m
               total        used        free      shared  buff/cache   available
Mem:          773399      132558        5188           4      641595      640841
Swap:            976         868         108

Kann mir das jemand erklären?

[mat6937]

Obwohl in der /etc/sysctl.conf vm.swappiness = 1 steht fängt er immer wieder an den swap zu füllen, aber warum?

Kann mir das jemand erklären?

Evtl. findest Du die Erklärung/Antwort auf deine Frage, in: https://www.howtogeek.com/449691/what-i ... change-it/

[Livingston]

Kommentier das swap-Device aus der fstab aus. Anschließend update-initramfs -u. Sollte reichen.

[cosinus]

Das wurde letztes Jahr doch schonmal gefragt
Macht es Sinn, die beiden Themen zusammenzuführen?

[bluestar]

Kommentier das swap-Device aus der fstab aus. Anschließend update-initramfs -u. Sollte reichen.

Ein Betrieb ohne Swap ist nicht zu empfehlen, es gibt aber in Form von zram-tools Abhilfe, da wird ein Teil des RAMs als komprimierter Swap verwendet.

[wanne]

Kommentier das swap-Device aus der fstab aus. Anschließend update-initramfs -u. Sollte reichen.

Meine große Empfehlung: Schmeiß einfach 700GiB RAM raus dann wird noch viel weniger RAM benutzt!!!! Genial, wie man Ressourcen sparen kann.

Obwohl in der /etc/sysctl.conf vm.swappiness = 1 steht fängt er immer wieder an den swap zu füllen, aber warum?

Am ende ist es am besten, wenn du dir den Link durch ließt.
Aber im Moment ist nicht mal 0,6% deines RAMs wirklich frei. Ich weiß nicht, was du sonst genau gesetzt hast und min_pages/min_free_kbytes aussieht. Aber es dürfte fast sicher sein, dass dein RAM irgend wann mal "voll" war. Du hast die swappiness auf 1 und nicht 0 gesetzt.
Bei 0 und no overcommit geht der Linux Kernel strikt in der Reihenfolge vor, wenn RAM aus geht: Zuerst wird der Cache weg geworfen, Memmapped files auf die Platte geschrieben und Programme ausgelagert. Als zweites werden Programmdaten in den Swap geschoben. Wenn auch der aus geht Programme abgeschossen.

Beispiel:

Code: Alles auswählen

int fdin = open (argv[1], O_RDONLY)
struct stat statbuf;
fstat (fdin,&statbuf);
char *src = mmap (0, statbuf.st_size, PROT_READ, MAP_SHARED, fdin, 0)
char *dst = malloc(statbuf.st_size);
memcpy (dst, src, statbuf.st_size);

src würde bei free unter Cache fallen und in Schritt eins würde ins Dateisystem geschrieben werden. dst würde unter used fallen und in Schritt zwei in den SWAP ausgelagert werden.


Normalerweise wird schritt eins und zwei parallel gemacht. Bei 1 in erster Linie Schritt eins ganz wenig schritt zwei bei 100 viel schritt zwei und wenig schritt eins. Im vorherigen Beispiel ist offensichtlich warum es nicht unbedingt sinnvoll ist, das eine vor dem anderen zu bevorzugen.


In deinem Fall: Wenn der RAM aus geht, fängt er an (Wenn auch zu extrem kleinen Anteilen) selten genutzte Programmdaten weg zu swappen. Da das nur die seltenst genutzten sind, bleiben die dann da a für ewigkeiten. Klassisches Beispiel auf einem Desktop ist SSDM/LightDM. Wird am Anfang ein mal benutzt liegt dann im RAM und bleibt bis zum runter fahren/abmelden. Ist sinnvoll, dass so lange in den Swap zu legen, damit mehr Platz für Cache ist.
Für mich sieht das aber extrem ungesund aus. Ich kenne den Anwendungszweck nicht. Aber wenn das keine Archivserver o.ä. ist, auf dem massiv Daten geschrieben und nie gelesen werden muss der Server die ganze Zeit Cache weg schmeißen um eventuell lange Zeit nutzlose Daten im RAM zu halten. Wer sich ~800GiB RAM leisten kann, kann sich auch ein paar duzend GiB NVME-SWAP leisten, die ermöglichen, dass der ein bisschen Programm Daten auslagern kann um mehr Platz für Cache zu haben.

[cosinus]

Für mich sieht das aber extrem ungesund aus. Ich kenne den Anwendungszweck nicht. Aber wenn das keine Archivserver o.ä. ist, auf dem massiv Daten geschrieben und nie gelesen werden muss der Server die ganze Zeit Cache weg schmeißen um eventuell lange Zeit nutzlose Daten im RAM zu halten. Wer sich ~800GiB RAM leisten kann, kann sich auch ein paar duzend GiB NVME-SWAP leisten, die ermöglichen, dass der ein bisschen Programm Daten auslagern kann um mehr Platz für Cache zu haben.

Hatte er das nicht kurzt angerissen? Das scheint ein KVM-Host zu sein, also ein Server, der VMs bewirtet und seinen physischen Speicher eigentlich nur für diese virtuellen Maschinen bereitstellt. Der Host selbst braucht diesen Speicher eigentlch nicht.

Mich würde mal interessieren, wie viele VMs dieser Wirt bereitstellt und wieviel GiB man insgesamt den VMs zugeordnet hat. Bei uns im Büro haben wir dieses Thema auch grade aktuell, nur dass wir auf VMWare vSphere setzen mit zwei Hosts mit je 512 GiB RAM.

[wanne]

Hatte er das nicht kurzt angerissen? Das scheint ein KVM-Host zu sein, also ein Server, der VMs bewirtet und seinen physischen Speicher eigentlich nur für diese virtuellen Maschinen bereitstellt. Der Host selbst braucht diesen Speicher eigentlch nicht.

Mich würde mal interessieren, wie viele VMs dieser Wirt bereitstellt und wieviel GiB man insgesamt den VMs zugeordnet hat. Bei uns im Büro haben wir dieses Thema auch grade aktuell, nur dass wir auf VMWare vSphere setzen mit zwei Hosts mit je 512 GiB RAM.

Kommt immer drauf an, worauf du optimierst. Wenn die Platte der VM ein "lokales" "device" ist (iSCSI/qcow2/vdi), kann es in Summe sinnvoll sein, den VMs wenig RAM zu geben und die dann swappen zu lassen. Dein relativ großer Cache fängt das dann auf. Da der SWAP in der VM real nur im RAM des Hostes liegt, der rasend schnell ist. So erlaubst du es einen Teil der Speicherressourcen dynamisch nach bedarf zu verteilen während ein gewisser Teil des RAMs garantiert bleibt. Dann willst du ne kleine Swappiness im Host aber eine große drüber. Ähnlich aber noch extremer ist es einfach massiv Overprovisioning zu betreiben und im Host einen Haufen swap mit viel swappiness zu haben. Dann bekommt der, der am meisten nutzt/benötigt den meisten RAM und wenig genutzte VMs sind lahm. Funktioniert natürlich nur, wenn deine VM-Nutzer gutmütig sind und nicht absichtlich Last erzeugen, damit ihr System flotter wird.
Anders sieht es aus, wenn man einen Service nach Bezahlung bereit stellen will: Dann willst du dem Host fast keinen RAM und SWAP geben aber auch nicht overcommiten. Dann bekommt jeder die Ressourcen, die er bezahlt hat garantiert und er kann sich selbst überlegen, wie er die Nutzt. Hat aber halt den Nachteil, dass ungenutzte Resourcen brach liegen statt anderen VMs zu gute zu kommen.

[Livingston]

Kommentier das swap-Device aus der fstab aus. Anschließend update-initramfs -u. Sollte reichen.

Ein Betrieb ohne Swap ist nicht zu empfehlen, es gibt aber in Form von zram-tools Abhilfe, da wird ein Teil des RAMs als komprimierter Swap verwendet.

Nicht, dass ich das Abschalten des swap für sinnvoll erachte, aber wenn man es ausschalten will, dann so.
Hab ja keine Ahnung, was sein Plan ist.

[slu]

Das wurde letztes Jahr doch schonmal gefragt
Macht es Sinn, die beiden Themen zusammenzuführen?

Ja so langsam dämmert mir das wieder, allerdings habe ich es noch nicht verstanden wie ich feststellen muss.
Sorry für den doppelten Thread

Ein Betrieb ohne Swap ist nicht zu empfehlen, es gibt aber in Form von zram-tools Abhilfe, da wird ein Teil des RAMs als komprimierter Swap verwendet.

Würde ich damit das ganze nicht einfach verschieben, heißt es wird noch mehr RAM verwendet weil er komprimiert wird?
Auf den Workstations setzen wir tatsächlich zram-tools ein und das hilft enorm die Systeme flüssig zu halten.

Hatte er das nicht kurzt angerissen? Das scheint ein KVM-Host zu sein, also ein Server, der VMs bewirtet und seinen physischen Speicher eigentlich nur für diese virtuellen Maschinen bereitstellt. Der Host selbst braucht diesen Speicher eigentlch nicht.

Genau so ist es, es ist ein KVM Host der nur dazu dient VMs zur Verfügung zu stellen.
Insgesamt laufen derzeit 8 VMs (ein Windows Server, ansonsten nur Debian/Ubuntu VMs).

Ich kann dir nicht genau sagen wie viel RAM vergeben wurde (müsste ich morgen nachschauen) es sind aber unter 512 GB.

Wenn ich eure Beiträge so lese (vielen dank an dieser Stelle!), ist es beim KVM Host dann nicht einfach so das die qcow2 Images/Dateien im buff/cache landen und dieser auf dem KVM Host einfach immer voll ist?
Dann wäre das ja völlig in Ordnung und der RAM optimal genutzt?
Oder schreibe ich hier völligen Mist?

[slu]

Aber im Moment ist nicht mal 0,6% deines RAMs wirklich frei. Ich weiß nicht, was du sonst genau gesetzt hast und min_pages/min_free_kbytes aussieht. Aber es dürfte fast sicher sein, dass dein RAM irgend wann mal "voll" war. Du hast die swappiness auf 1 und nicht 0 gesetzt.
Bei 0 und no overcommit geht der Linux Kernel strikt in der Reihenfolge vor, wenn RAM aus geht: Zuerst wird der Cache weg geworfen, Memmapped files auf die Platte geschrieben und Programme ausgelagert. Als zweites werden Programmdaten in den Swap geschoben. Wenn auch der aus geht Programme abgeschossen.

Ich hab inzwischen mal mit swapoff -a den Swap testweise komplett ausgeschaltet.

Code: Alles auswählen

cat /proc/sys/vm/min_free_kbytes
112564

Der Server bzw. die VMs laufen übrigens ohne Probleme.

[wanne]

Wenn ich eure Beiträge so lese (vielen dank an dieser Stelle!), ist es beim KVM Host dann nicht einfach so das die qcow2 Images/Dateien im buff/cache landen und dieser auf dem KVM Host einfach immer voll ist?
Dann wäre das ja völlig in Ordnung und der RAM optimal genutzt?

Ja. Wenn die qcow2 Images auf dem gleichen Host liegen, wird genau das passieren. Optimal ist das aber IMHO nicht. Wie gesagt: Wenn du dem Host etwas mehr SWAP gibst, wird er vermutlich ein paar der ungenutzten Programme in der Windows-VMs in den Swap verfrachten und dafür häufig genutzte Teile der qcow2-Dateien in den RAM packen. Im Schnitt ist das von Vorteil, weil letzteres häufiger genutzt wird. Es Kommt aber eben auf dein Verhältnis zu den Nutzern an. Denn am Ende "betrügst" du sie ein bisschen, weil Sachen die sie in den vermeintlich RAM packen real auf deiner SWAP-Partition landen (und dafür Zugriffe auf die vermeintlich langsame Festplatte plötzlich schnell sind.) Mit zahlenden Kunden macht man das eher nicht. Für intern ist das durch aus sinnvoll.
Da du ja sowieso ne Menge RAM für Cache übrig hast, wird der Unterschied nicht enorm sein, Aber da der Server trotz extrem kleiner Swapiness den Swap mehr oder weniger voll ausnutzt, ist da offensichtlich Optimierungspotential.

Ich hab inzwischen mal mit swapoff -a den Swap testweise komplett ausgeschaltet.

Wie gesag: Du kannst auch problemlos 500 von deinen 800GiB RAM raus werfen und die VMs werden weiter laufen. Nur halt stinken lahm. Das selbe verursachst du halt mit keinem (oder deinem extrem kleinen) Swap. Klar du kannst immer mehr RAM drauf werfen und das system wird irgend wann trotzdem schnell genug. So wie man mit nem heutigen Auto auch mit angezogener Handbremse problemlos 120 fahren kann. Der Motor ist stark genug. Vor 100 Jahren wäre es beim Anfahren eventuell ein Problem gewesen. Sinnvoll ist es nicht.

Ein Rechner mit 2GiB RAM wird immer schneller sein als einer mit 1GiB RAM und 1GiB Swap. Aber ein Rechner mit nur 1GiB RAM wird (bei sinnvoll eingestellter swappiness) immer lahmer sein als einer mit 1GiB RAM+1GiB Swap. Da Swap üblicherweise quasi umsonst ist, ist das sinnvoll. Deswegen macht der Installer das. Der Fall, dass Programme wegen zu wenig RAM/Swap wirklich nicht mehr laufen ist seit vielen Jahren defakto vorbei.

[slu]

Im Schnitt ist das von Vorteil, weil letzteres häufiger genutzt wird. Es Kommt aber eben auf dein Verhältnis zu den Nutzern an. Denn am Ende "betrügst" du sie ein bisschen, weil Sachen die sie in den vermeintlich RAM packen real auf deiner SWAP-Partition landen (und dafür Zugriffe auf die vermeintlich langsame Festplatte plötzlich schnell sind.) Mit zahlenden Kunden macht man das eher nicht. Für intern ist das durch aus sinnvoll.

Keine Sorge das ist ein interner Server, wir bieten keine Dienste an sonst hätte ich mir das KVM Projekt gar nicht zugetraut.
Ich hatte mich auch tatsächlich gehen Proxmox entschieden (auch wenn mir das Projekt sehr gut gefällt) weil wir schon sehr lange ein KVM Server auf Debian mit libvirt/virt-manager betreiben.

Da du ja sowieso ne Menge RAM für Cache übrig hast, wird der Unterschied nicht enorm sein, Aber da der Server trotz extrem kleiner Swapiness den Swap mehr oder weniger voll ausnutzt, ist da offensichtlich Optimierungspotential.

Das ist genau der Punkt der mir nicht klar ist, ich glaube das ist mein "Hänger"...
Wenn ich jetzt mehr Swap zur Verfügung stelle, würde der dann nicht immer voller werden und der buff/cache bleibt gleich voll?
Die qcow2 Images sind ja sehr groß und ständig in Bearbeitung, da macht es ja schon Sinn ein großer Teil immer im RAM zu halten.

Ich möchte das jetzt erst Mal für mich zusammen fassen:
1) die VMs sind schnell und zeigen keine Probleme
2) ich kann den Swap abschalten ohne das ich mein System in einen kritischen Zustand bringe
3) ich könnte zram aktivieren um etwas RAM zu sparen

Danke für die Geduld und eure Beiträge.

[wanne]

Wenn ich jetzt mehr Swap zur Verfügung stelle, würde der dann nicht immer voller werden und der buff/cache bleibt gleich voll?

Wenn ich die verdorbenen Sachen aus meinem Kühlschrank weg werfe, und durch frische ersetze bleibt der gleich voll. Wird aber deutlich nützlicher. Die Frage ist, WAS du da drin hast.
RAM ist schneller als die Festplatte. Am liebsten würdest du deswegen alle Daten im RAM haben und nur für den Fall, dass man runter/hoch fährt Sachen auf die Festplatte schreiben. Router, die üblicherweise nur wenige Megabyte Daten haben, machen üblicherweise genau das. Für viele anderen Systeme wäre ausreichend viel RAM für so einen Betrieb aber ein bisschen teuer, weshalb man seine Daten üblicherweise auf die Festplatte schreibt. Aber wenigstens die häufigst genutzten Daten werden nochmal im RAM behalten. Deswegen werden Systeme schneller, wenn sie mehr RAM haben. Wenn dein Firefox nicht jedes mal von der Platte gelesen werden muss sondern im RAM bleibt, ist der flotter. Je mehr RAM desto mehr Cache desto häufiger sind Sachen schon im RAM.
Umgekehrt geht das nicht so einfach: Wenn du ein Word-Dokument aufmachst, dass du nie abgespeichert hast, kann dein Rechner das, völlig egal wie lange du daran nichts machst, nicht einfach aus dem RAM werfen und falls es dann doch gebraucht wird wieder von der Platte lesen. Das sind etwa die Daten, die "free" als "used" bezeichnet.
Wenn du jetzt aber mit dem Firefox surfst macht es durchaus Sinn, das Word Dokument auf die Platte zu schreiben, damit der Firefox schnell im RAM läuft ohne von der Platte gelesen werden zu müssen. Dafür ist dann der Swap da.

Wenn du deinem System mehr swap und ne hohe swappiness gibst, wird der used Anteil vermutlich runter gehen und die caches dafür hoch. "used" macht aber eh nur ~20% deines RAMs aus. Und große Teile davon, werden sicher auch häufig benutzt, sodass es gar nicht sinnvoll ist, die in den SWAP zu legen um mehr platz für seltener genutzte Caches zu haben. Du kannst deinen SWAP graduell erhöhen. Dann wirst du merken, dass der Kernel das GiB dass du ihm zuvor gegeben hast weitestgehend voll macht. Denn es gibt sicher eine menge Daten, die selten angefasst werden aber nicht nochmal auf der Festplatte vorhanden sind. Aber sicher keine 100GiB, da es ab einem gewissen Punkt nicht mehr sinnvoll ist.


So und jetzt Spezialfall Windows-VMs: Windows hat ja schon nen swap-file in Form der pagefile.sys (Ich glaube unter Windows 10 heißt es auch irgend was mit swap.sys) Kann das geschilderte also eh schon selbst machen, während das Linux drunter ja gar nicht versteht, was jetzt Firefox und Word ist sondern nur sieht wo am häufigsten zugegriffen wurde. Die Windows VM kann also eigentlich viel besser entscheiden, was in den RAM soll und was nicht. Der Grund ist der, dass die VM ja nur ihren eigenen verwalten darf. Wenn du dem Host Swap gibst, kann er den RAM eine wenig genutzte VM in den Swap verfrachten (die sich dann über einen verdammt langsamen RAM wundert) und dafür z.B. die pagefile.sys einer Stark beanspruchten VM in den RAM packen, (die sich dann über verdammt schnellen Swap freuen kann.) Sprich: RAM wird weniger fest nach Konfiguration sondern dynamisch nach bedarf verteilt. Oder anders: Stark beanspruchte VMs können andere ausbremsen, die gerade eh nichts zu tun haben und damit schneller werden. Ob dieses verhalten gewünscht oder unerwünscht ist, musst du selbst entscheiden.

Im Optimalfall lässt der eine der nen besonders anspruchsvollen Job hat, den irgend wann nachts laufen und bekommt den gesamten RAM während die restlichen VMs in den Swap verfrachtet werden. Im worst case programmiert er irgend einen Mist der ohne Ende auf der Palatte rum rödelt und bremst damit die ganze Abteilung aus.

[slu]

Danke wanne für die ganze Erklärung und die Beispiele!

Das Thema Swap ist mir jetzt klar und hatte ich in der Vergangenheit völlig falsch verstanden, nämlich so:
[Falsch] "Swap nimmt das System bevor ihm der RAM ausgeht und es damit zum Absturz kommt" [/Falsch]

Als Quereinsteiger merke ich immer wieder das ich manche Themen einfach nicht weiß.