Ich habe SWAP in FreeBSD 13, aber er wird nicht genutzt?

pit234a

Well-Known Member
Dieses Mal komme ich vollkommen anders, als bisher.

Bisher habe ich immer die Meinung vertreten, dass SWAP ein Relikt aus alter Zeit ist und bei modernen Systemen in modernen Rechnern mit ausreichend RAM nicht nötig sein sollte und deshalb auch ein System ohne SWAP gut und stabil laufen (können) sollte.

Nun habe ich eine NVME übrig gehabt und nach einigen Versuchen und aus unterschiedlichen Gründen (hauptsächlich wegen mangelnder Redundanz) dagegen entschieden, mein System davon zu booten. Aber als schneller, lokaler Speicher wollte ich sie schon nutzen und dann habe ich da auch mal einen gewaltigen SWAP darauf angelegt.

Mein System hat 64G RAM und deshalb machte ich mal 120G SWAP auf der NVME frei. Der wird auch benutzt, aber eben so gut wie gar nicht!
Grundsätzlich ist das ja gut.
Aber tatsächlich habe ich Applikationen, die mehr RAM wollen und dann hängen bleiben. Nämlich hauptsächlich zwei Win10 VMs in VirtualBox.

Nun gebe ich denen weniger RAM und dann ist gut, aber ich frage mich halt, ob ich womöglich etwas destruktiv eingestellt habe, als ich noch keinen SWAP haben wollte oder wie man grundsätzlich in FreeBSD die "Swappiness" beeinflussen kann.
Dass die beiden Windows-VMs trotz vorhandenen SWAPs mit Fehlermeldungen über zu wenig RAM ihren Dienst einstellen, sehe ich nicht als schreckliches Problem an. Ich kann die nacheinander starten und ich kann denen jeweils weniger RAM zuweisen und alles ist gut.

Aber warum werden meine 120G SWAP so gut wie nicht angerührt? was im beschriebenen Fall dann tatsächlich zu System-Hängern führt, wenn eine weitere VM keinen RAM mehr bekommen kann, obwohl ausreichend SWAP vorhanden ist.

Derzeit habe ich dies:
Code:
pit@Celsius ~:- > sysctl -a | grep swap
1 PART nvd0p2 128765132800 512 i 2 o 629145600 ty freebsd-swap xs GPT xt 516e7cb5-6ecf-11d6-8ff8-00022d09712b
z0xfffff803b60fe200 [shape=box,label="SWAP\nswap\nr#3"];
      <name>swap</name>
        <type>freebsd-swap</type>
vm.swap_enabled: 1
vm.domain.0.stats.unswappable: 0
vm.swap_idle_threshold2: 10
vm.swap_idle_threshold1: 2
vm.swap_idle_enabled: 0
vm.disable_swapspace_pageouts: 0
vm.stats.vm.v_swappgsout: 0
vm.stats.vm.v_swappgsin: 0
vm.stats.vm.v_swapout: 0
vm.stats.vm.v_swapin: 0
vm.stats.swap.free_completed: 0
vm.stats.swap.free_deferred: 0
vm.nswapdev: 1
vm.swap_fragmentation:
vm.swap_async_max: 4
vm.swap_maxpages: 129900512
vm.swap_total: 128765132800
vm.swap_reserved: 9636758142976
 
Mein System hat 64G RAM und deshalb machte ich mal 120G SWAP auf der NVME frei.
Das ist eher kontraproduktiv, va. am Desktop, da swap auch adressiert werden muss und daher am RAM nochmals weggeknappst wird. Swap ist als Auffangnetz zu sehen, quasi der letzte Strohhalm bevor der OOM Dienste wegknipst und ist daher in der 'Benutzungspriorität' ganz niedrig angesiedelt, weil das auf dem Host den I/O-delay hochdrückt -> insgesamt ganz schlecht für alles.
VM-Benutzung einbezogen würde ich zu max. 32GB raten, ggf. ist der Einsatz der NVMe als L2ARC sogar effektiver.
Großer swap ist eher sinnvoller am Server der monatelange uptime hat. Der wird dann über lange Laufzeit auch gefüllt, wenn überhaupt benötigt.

aber ich frage mich halt, ob ich womöglich etwas destruktiv eingestellt habe
Da müsste man wissen, waswowiewann eingestellt wurde. :)
Nämlich hauptsächlich zwei Win10 VMs in VirtualBox.
Wo liegen die VMs drauf? Wo schreiben die VMs ihren eigenen swap hin? Auch hier wäre die Überlegung die VMs einfach nur auf die NVMe zu legen. Oder swap auf 32GB zu setzen und die VMs auf die Partition hintendran.

Aber warum werden meine 120G SWAP so gut wie nicht angerührt?
Das hängt hauptsächlich am trägen ARC und das verträgt sich nicht mit dem Start einer VM, die auf einen Schlag nen Batzen RAM anfordert. Es passt auch nicht mit swap zusammen, den kann man auch nicht 'schnell' befüllen, wie ein VM-Start das bräuchte.

Aktuell genauere Insights habe ich nicht, https://forums.freebsd.org/threads/understanding-memory-management.84695/post-563011 ist aber ein guter Einsteiger. ;)
 
ggf. ist der Einsatz der NVMe als L2ARC sogar effektiver.
Ja. Das finde ich auch ne gute Idee (als Ergänzung: kann man machen via zpool add <pool> cache <device> ; das Device ist idealerweise ne Partition auf der SSD). Also wenn die NVMe-SSD sowieso für sonst nix genutzt wird, liegt es nahe da den Cache drauf zu legen. Man könnte auch noch zusätzlich überlegen, ob man da sowas wie /tmp , /var/tmp , /var/run etc. drauf legt. Hat jetzt nix mit dem beschriebenen Problem zu tun, aber wenn man sich schon entschieden hat diese SSD für temporäre Dinge zu nutzen, dann doch gerne alles.
Ebenso gut finde ich Deine Idee die Swap-Größe weniger ausschweifend zu machen. Einmal natürlich aus dem Grund, den Du genannt hast. Gibt aber noch (mindestens) einen Weiteren: Es kann ja mal passieren, das ein Prozess z.B. durch einen Bug zu ausschweifend mit dem RAM-Verbrauch wird und so alles in den Swap drückt. Da Swap verhältnismäßig langsam ist, führt das dazu das das System insgesamt kaum noch reagiert und es dann sogar schwierig wird den betreffenden Prozess manuell abzuschießen.

Generell ist Swap zu haben nicht verkehrt. Es funktioniert dann am besten, wenn man (viele) RAM-Anteile hat die längere Zeit nicht angefasst werden und die dann einfach mal rausgeschoben werden können und man mehr physischen RAM für die Dinge die gerade anstehen zur Verfügung hat.

Ansonsten müsste man einfach mal gucken, wer denn so die großen RAM-Fresser sind. 64GB sind ja nicht gerade ne knapp bemessene RAM-Ausstattung. Da dürften eigentlich das System + 2 oder 3 VMs nicht das große Problem darstellen.

Das hängt hauptsächlich am trägen ARC
Apropos. Evtl. macht es in dem Szenario deshalb Sinn den Umfang des (in-memory-)ARC zu begrenzen. Es gibt ja dafür die Systemvariable vfs.zfs.arc.max.

Dass die beiden Windows-VMs trotz vorhandenen SWAPs mit Fehlermeldungen über zu wenig RAM ihren Dienst einstellen
Wer gibt denn da die Meldung und wie sieht die konkret aus?

Nur so am Rande und der Neugier halber: Wieso eigentlich VirtualBox, wo es doch bhyve gibt?
 
Das hängt hauptsächlich am trägen ARC und das verträgt sich nicht mit dem Start einer VM, die auf einen Schlag nen Batzen RAM anfordert. Es passt auch nicht mit swap zusammen, den kann man auch nicht 'schnell' befüllen, wie ein VM-Start das bräuchte.

Sollte das nicht mit ZoL und FreeBSD 13 eigentlich großteils behoben sein? Zumindest bei mir gabs solche Probleme dann nicht mehr.
Aber wie schon gesagt, für das VM Problem macht es ev. Sinn den ARC zu begrenzen, RAM/2 oder 2*RAM/3 wären hier für ein Desktopsystem sicher ein brauchbarer Wert, von Spezialuscases mal abgesehen.
 
Sollte das nicht mit ZoL und FreeBSD 13 eigentlich großteils behoben sein?
Der ARC reagiert snappier, ja. Dem Problem wurde entgegengewirkt, aber das Grundproblem ist ja nicht durch Software lösbar. Wenn $prozess halt jetzt asap sofort soviel RAM anfordert, den die Maschine gerade nicht hat, weder in frei verfügbar noch physisch vorhanden und weder ARC trotz Optimierung nicht schnell genug freischaufelt, dann rennt man ins Problem. Swap ist trotz NVMe trotzdem nochmal langsamer, zäher, eh niedrigst priorisiert und eine VM starten ist das klassische Beispiel dafür. Wenn man noch pci-passthrough hat, wird das nochmals verstärkt.
Am Ende hilft da nur mehr RAM bzw. etwas Spielerei, zeitversetzter Start der VMs, denen weniger RAM zuweisen, lange laufen lassen, damit L2ARC oder swap über Zeit auslagern können.
Es funktioniert dann am besten, wenn man (viele) RAM-Anteile hat die längere Zeit nicht angefasst werden und die dann einfach mal rausgeschoben werden können und man mehr physischen RAM für die Dinge die gerade anstehen zur Verfügung hat.
Genau. Mittlerweile muss der L2ARC nach einem reboot auch nicht mehr voll-/warmlaufen. In Aktion habe ich das aber noch nicht gesehen. :)

Apropos. Evtl. macht es in dem Szenario deshalb Sinn den Umfang des (in-memory-)ARC zu begrenzen. Es gibt ja dafür die Systemvariable vfs.zfs.arc.max.
Jep, bei VM-Betrieb kann das Limit setzen immer noch Sinn ergeben. Rantasten kann man sich mal mit Begrenzung auf 3/4 des RAM, testen über 2-3 Tage und dann nochmal mit 1/2 oder so um den Dreh.

Achja, gern vergessen bei den datasets, auf denen VMs liegen ist zfs set primarycache=metadata /zroot/meinevm zu setzen. Ansonsten wird doppelt gecacht, ist Verschwendung und behindert sich gegenseitig. Das sollte man zuerst tun, dann erst testen mit zusätzlichem ARC-Limit.
secondarycache=metadata wäre noch zu setzen, das greift aber erst, wenn man auch einen L2ARC hat.
 
danke schon mal für die Beiträge.

Last mich mal versuchen, die unterschiedlichen Aspekte und Fragen anzugehen, ohne jeweils die konkreten Stellen aus den vorhergehenden Beiträgen zu kopieren.
Vielleicht zurück auf Anfang.
Am Anfang wollte ich gar keinen SWAP, rein überhaupt nicht, weil ich das eben für überholt halte. Diskussionen hatten wir hierzu schon und ich wurde schon belehrt.
Bei jeder neuen FreeBSD-Version spiele ich mit den vfs.zfs.arc.max-Werten und nehme die zunächst mal einfach raus. Bisher hatte mir das nie gefallen: mein Desktop läuft in der Regel auch 24x7 und macht in der Nacht die täglichen Backups nach unterschiedlichen Zielen. Im Laufe der Zeit wird so der RAM nahezu komplett belegt. Dabei ist das gar nicht lange, schon nach wenigen Tagen ist der freie RAM "verbraucht".
Seit einiger Zeit habe ich das Problem, dass mein PC sich in der Nacht gelegentlich abschaltet. Gelegentlich, aber äußerst sporadisch. Inzwischen habe ich das Verhalten dann auch am Tage erlebt, so dass es in meinen Augen auf ein HW-Problem zeigt. Davor aber hatte ich auch meinen Starrsinn in Verdacht, ganz ohne SWAP auskommen zu wollen und legte mir ein Swapfile an, was aber nicht die Lösung des Problems war.
Nachdem ich die NVME hatte, war ich zwar neugierig darauf, aber auch irgendwie ratlos, wie ich die nun wirklich sinnvoll nutzen könnte und ob überhaupt in diesem PC. Sie war immerhin schon gut gebraucht.
Wie es der Zufall manchmal so will, bekam ich noch während meiner Bedenkzeit eine zweite NVME geschenkt. Inzwischen hatte ich mir nämlich erst mal ein Gehäuse gekauft, also quasi einen Adapter für NVME auf USB und nutzte die erste NVME darin als externes Medium. Das ist schon ziemlich cool.
Einen zweiten solchen Adapter wollte ich aber zunächst nicht und also steckte ich die neue NVME nun wirklich in den PC, aktivierte sie und ZFS-send-ete erst mal mein laufendes System darauf, rein, um meine Neugier zu befriedigen. Nach wenigen Wochen der Begeisterung erlebte ich aber einige bisher nicht gekannte Fehler in diesem Zpool, bekam kalte Füße und aktivierte wieder mein System auf den alten SSDs.

Diese NVME ist noch im PC, aber sie genießt nun nicht mein maximales Vertrauen, um etwa den L2ARC oder sonstige wichtige Sachen darauf zu legen, die dann ohne Redundanz dort laufen würden. Langsam aber zuverlässig gefällt mir besser, als hier noch Performance raus holen zu wollen.

OK, aus der vorherigen Partitionierung bot es sich an, eine SWAP mit 120G dort zu benutzen. Ohne jetzt den großen Sinn damit zu erfüllen, eher als eine Art schneller und einfacher Test und als schneller und einfacher Ersatz für mein Swapfile.

VirtualBox nutze ich nun schon sehr viel länger, als es bhyve gibt und mit mehreren Maschinen, die ich auch auf anderen PCs nutze, teilweise auch mit anderen Betriebssystemen. Das ist für mich einfach einfach, ich brauche nicht neu zu lernen und mich jedes mal erst um zu sehen. Und die VMs laufen auch fast nie und ich brauche die auch nicht alle gemeinsam zu starten. Das war nun nur ein Test, um endlich doch mal zu sehen, dass dieser SWAP überhaupt auch in nennenswerter Größe angefasst wird.
Wird er aber nicht.

Also, wenn das nicht durch meine Einstellungen verhindert wird, dann werden nie mehr als einige MB im SWAP benutzt. Immer weit weniger, als 1G.
Das macht mich wieder mal nachdenklich.
Wenn das System wirklich SWAP braucht, um anständig zu funktionieren, aber tatsächlich nur minimalen Gebrauch davon macht, dann wäre es doch vielleicht gar nicht so dumm, einen kleinen SWAP im RAM selbst anzulegen. Nicht so dumm, wie mir die Idee zunächst erschienen ist.
 
Am Anfang wollte ich gar keinen SWAP, rein überhaupt nicht, weil ich das eben für überholt halte.
Grundsätzlich ist Swap zu haben nicht verkehrt. Das muss (und sollte) ja nicht übermäßig viel sein. Ist aber ganz praktisch, um Verbrauchsspitzen aufzufangen und gibt natürlich dem System auch mehr Raum zum optimieren.
Insofern würde mich mal interessieren welche harten Argumente gegen Swap sprechen (also abseits von reinen read-only-Systemen).

Bei jeder neuen FreeBSD-Version spiele ich mit den vfs.zfs.arc.max-Werten und nehme die zunächst mal einfach raus.
Also grundsätzlich funktioniert ein Dateisystem ja auch ohne Cache. Der ist ja primär ein Mittel zu Leistungssteigerung (auch wenn der ARC bei ZFS sicher ne größere Bedeutung hat als Cache bei anderen Dateisystemen).

Nacht die täglichen Backups nach unterschiedlichen Zielen.
Gerade für Backups ist viel Cache eher sinnlos. Cache entfaltet ja genau dann seine Wirkung, wenn ein und die selben Daten mehrmals hintereinander gelesen/geschrieben werden. Denn der Geschwindigkeitsgewinn kommt ja daher, das statt die Daten umständlich aus dem Dateisystem rauszusuchen, die aus dem schnelleren Cache-Speicher kommen.

Beim Backup, wo ne große Menge Daten einfach nur mehr oder weniger sequentiell von A nach B geschrieben werden sollen, bringt Cache dann kaum was. Ganz überflüssig ist er nicht, weil es Metadaten gibt auf die mehrfach zugegriffen wird und auch das den Zieldatenträger angeht kann es ganz sinnvoll sein ein Write-Cache zu haben. Aber ist jetzt keine Paradedisziplin für Cache.

Von daher ist kein vfs.zfs.arc.max zu setzen wegen Backups blödsinnig. Man könnte sogar umgekehrt sagen: Gerade hier wäre es angebracht, damit nicht der Cache unnötigerweise zu viel beansprucht wird.

dass mein PC sich in der Nacht gelegentlich abschaltet
Ist jetzt zwar nicht primär Inhalt dieses Threads, aber könnte man ja mal gucken, ob dem irgendwas voraus geht woraus man nähere Informationen ziehen könnte. Ich denke da so an Kernel-Dumps und ähnliches.
Aber ja. Könnte ein Hardwarefehler sein. Möglicherweise Netzteil oder so. Aber das ist natürlich wildes herumspekulieren.

Diese NVME ist noch im PC, aber sie genießt nun nicht mein maximales Vertrauen
Verstehe ich. Aber dann würde ich auch kein Swap drauf legen wollen.
Dann würde ich es wirklich nur für Daten verwenden, wo es nicht drauf ankommt. Browser-Cache, Cache für den Mediaplayer oder weiß der Geier.

Wenn das System wirklich SWAP braucht, um anständig zu funktionieren
Ob es das wirklich braucht, weiß ich jetzt nicht. Gut. Bei mir haben alle Systeme Swap. Daher hab ich jetzt keine Gegenerfahrung.

einen kleinen SWAP im RAM selbst anzulegen
Naja. Swap im RAM wäre ja so ne Katze-beißt-sich-in-den-Schwanz-Geschichte.
Was man aber machen kann ist einfach eine Swapdatei benutzen. Das ist ne unkomplizierte Geschichte, wenn man dem System ein bisschen Swap spendieren möchte, ohne aber groß Aufwand reinstecken zu wollen.
 
Wenn du wirklich der SSD nicht traust, würde ich eher den L2ARC als das Swap darauf lassen, ersterer hat Checksums und wenn Kaputt egal, im Swap ist das nicht der Fall.
Am besten aber einfach mit SMART und badblocks testen.
 
L2ARC oder sonstige wichtige Sachen darauf zu legen, die dann ohne Redundanz dort laufen würden.
Das ist wurscht, das cache-device kann problemlos sterben. Das beeinträchtigt den pool nicht, außer dass es wieder langsamer als ohne L2ARC wird. Mittlerweile sogar auch SLOG, aber das würde ich prinzipiell trotzdem mindestens spiegeln, aber darum gehts ja nicht. :)
Nur als swap sterbend könnte es einen reboot provozieren, aber das wäre auch nicht wirklich tragisch.

Wenn das System wirklich SWAP braucht, um anständig zu funktionieren, aber tatsächlich nur minimalen Gebrauch davon macht,
Swap wird angefasst, wenn er gebraucht wird (oder wenn es wirklich sinnvoll ist, etwas lange nicht gebrauchtes reinzustecken), ansonsten vermieden. Das ist gewolltes und sinnvolles Verhalten, heißt aber im Umkehrschluss nicht, dass swap sinnlos ist. Im Zweifel und in der Bredouille kannst du immer noch eine weitere VM on top starten, der Überhang wird dann vom swap hergenommen.
 
Das ist wurscht, das cache-device kann problemlos sterben
Das gilt sicher, wenn das wegstirbt. Was aber beschrieben wurde da Datakorruption. Und da sieht die Sache anders aus. Man kann jetzt immer noch darüber streiten, wie dramatisch das ist. Aber ein Wohlfühlfaktor wird das nie. :-)

Nur als swap sterbend könnte es einen reboot provozieren, aber das wäre auch nicht wirklich tragisch.
Kommt drauf an. Erfahrungsgemäß passiert sowas ja, wenn man es am wenigsten gebrauchen kann. :-)
 
Von daher ist kein vfs.zfs.arc.max zu setzen wegen Backups blödsinnig. Man könnte sogar umgekehrt sagen: Gerade hier wäre es angebracht, damit nicht der Cache unnötigerweise zu viel beansprucht wird.
also nur dazu und zu SWAP:
Die Erfahrung lehrt es, aber trotzdem versuche ich es mit neuen FreeBSD-Versionen zuerst mal wieder, wie sich der Speicherverbrauch ohne alle Einstellungen verhält. Da hat sich schon ein wenig im Laufe der Zeit verändert und für mich ist es griffiger, die Erfahrung neu zu machen, anstatt Dokus zu lesen.
Dass ich bisher dann immer sehr schnell zurück zur Begrenzung von vfs.zfs.arc.max kam, ist halt so, aber weil der PC eben nicht so oft gebootet wird...

Über den Sinn von SWAP will ich nicht mehr generell diskutieren.
Ich halte es für obsolet und nutze es normalerweise (erfolgreich) nicht.
Allerdings wurde ich schon mehrfach dahingehend belehrt, dass selbst mit ausreichend RAM ein Vorteil in, wenn nicht gar ein MUSS zu SWAP besteht.
Deshalb hatte ich das halt nun mal an-getestet. Zunächst mit einem Swapfile, was auch deshalb sehr einfach ist, weil es automatisch auf die (in einem ZPool) zusammengefassten SSDs verteilt.
Dann einfach mal kurzerhand den unbenutzten Platz der NVME hinzugefügt und schließlich einfach alleine stehen lassen.
Mein Ziel ist es "eigentlich", wieder ohne SWAP zu fahren. Ich sehe darin keinen Sinn. Aber das ist meine pure Sturheit und mein Eigensinn.
Und wie gesagt, wurde ich deswegen ja schon mehrfach belehrt und glaube auch, dass ich keine Ahnung habe.

Also ganz klar, der vfs.zfs.arc.max wird wieder eingeschaltet oder ist bereits geschehen, der SWAP wird wieder ausgeschaltet (vermutlich komplett), aber die Idee, einen kleinen Bereich im RAM dafür zu reservieren bleibt einfach hängen.
Trotz "Katze in den Schwanz", klar.
Einfach nur, damit das System beruhigt seinen SWAP erkennt.

btw: bei mir liegt auch noch mehr im RAM:
Code:
mount | grep tmpfs
tmpfs on /tmp (tmpfs, local)
tmpfs on /var/log (tmpfs, local)
tmpfs on /var/run (tmpfs, local)
tmpfs on /var/tmp (tmpfs, local)
einen kleinen SWAP würde das sicher auch tragen können.
 
Die Erfahrung lehrt es, aber trotzdem versuche ich es mit neuen FreeBSD-Versionen zuerst mal wieder, wie sich der Speicherverbrauch ohne alle Einstellungen verhält.
Ist ja auch in Ordnung.
Aber Default-Werte sind nun mal default-Werte. Die sind ok aber je nach Einsatzzweck muss lohnt es natürlich, die anzupassen.

Über den Sinn von SWAP will ich nicht mehr generell diskutieren.
Es geht mir ja weniger darum darüber zu diskutieren oder irgendwen zu überzeugen (ist ja eh ne indivudelle Entscheidung, wo es ja kein grundsätzlich richtig oder falsch gibt).
Es habe ja lediglich gefragt, was es für Gründe gibt (um möglicherweise auch für mich selbst was daraus zu lernen).
Ich mein, Du stellst hier ja auch fragen damit Dir was erklärt wird. Aber wenn dann im Gegenzug Fragen kommen und die dann schlicht mit Verweis auf "keine Lust" nicht beantwortet werden, dann hat das schon etwas Egoistisches.
Vor allem weil Du ja nicht mal irgendwas wiederholen musst. Reicht ja ggf. wenn Du auf das/die entsprechende(n) Posting(s) verlinkst.

btw: bei mir liegt auch noch mehr im RAM:
Nach Nachteil bei RAM-Disk ist, das die Daten darauf üblicherweise nach nem Reboot weg sind.
Insbesondere bei Logdateien (/var/log) würde ich das für ungünstig halten, weil die ja auch gern retrospektiv für Fehleranalyse genutzt werden können. Ich denk da insbesondere an Dein vermuteten Hardwaredefekt. Evtl. findet sich ja ein Hinweis in den Logfiles. Wenn Du die natürlich immer wegwirfst, dann beraubt man sich der Möglichkeit da was zu finden.

Was /var/tmp angeht, so ist das explizit so definiert, das der Inhalt einen Reboot überlebt. Programme, die sich drauf verlassen, für die ist das dann natürlich ein Problem.

Du kennst Dich nicht gut aus. Das ist ok. Aber dann sollte man solche Spielereien, wo man sich potentiell Probleme reinzieht dann vielleicht auch nicht machen.

einen kleinen SWAP würde das sicher auch tragen können.
Ja. Aber wozu? eine kleine Swapdatei macht den Job genauso gut. Und das ohne das man basteln muss. Und ohne das man was von seinem wertvollen RAM dafür abknipsen muss.

aber die Idee, einen kleinen Bereich im RAM dafür zu reservieren bleibt einfach hängen.
Trotz "Katze in den Schwanz", klar.
Wie Du es letztlich machst, ist natürlich Dir überlassen.
Ich frag mich nur, wieso Du dann hier überhaupt im Forum fragst, wenn Du dann letztlich eh Hinweisen und Argumenten nicht zugänglich bist und dann doch alles anders machst wegen Eigensinn und so.

Mittlerweile muss der L2ARC nach einem reboot auch nicht mehr voll-/warmlaufen. In Aktion habe ich das aber noch nicht gesehen.
Ja. Wobei ich mir jetzt grad nicht sicher bin, ob man persistent l2arc explizit anknipsen muss.
 
Das gilt sicher, wenn das wegstirbt. Was aber beschrieben wurde da Datakorruption. Und da sieht die Sache anders aus. Man kann jetzt immer noch darüber streiten, wie dramatisch das ist. Aber ein Wohlfühlfaktor wird das nie. :-)

Datenkorruption sollte auch nicht vorkommen, da auch der l2arc die Checksums validiert und im Fehlerfall neu einliest. Gibt sogar einen eigenen Counter für L2ARC Checksum Errors.

:)
Nur als swap sterbend könnte es einen reboot provozieren, aber das wäre auch nicht wirklich tragisch.

Was da passiert kannst du eben nicht sagen, du kannst Datenkorruption haben, die das Program, von welchem die Speicherbereiche sind, nicht erkennt und dann passiert irgendwas. Im schlimmsten Fall auch Datenkorruption auf dem Hauptlaufwerk.
 
Ja. Aber wozu? eine kleine Swapdatei macht den Job genauso gut. Und das ohne das man basteln muss. Und ohne das man was von seinem wertvollen RAM dafür abknipsen muss.
Ja, da hast du natürlich schon Recht und das wird es dann wohl auch wieder werden.

Ich frag mich nur, wieso Du dann hier überhaupt im Forum fragst, wenn Du dann letztlich eh Hinweisen und Argumenten nicht zugänglich bist und dann doch alles anders machst wegen Eigensinn und so.
Das will ich kurz machen, weil ich da wohl falsch verstanden worden bin.
Ohne Hilfe hier im Forum könnte ich FreeBSD gar nicht bewältigen.
Es ist also ziemlich logisch, dass ich bei Fragen und Problemen hier aufschlage.

Diesmal wollte ich unbedingt mal sehen, dass der SWAP auch wirklich benutzt wird und erfahren, wie sich das dann anfühlt. Nachdem aber gar kein oder so gut wie gar kein SWAP angetastet wurde, fragte ich mich dann natürlich, ob ich vielleicht etwas falsch eingestellt habe.

Gibt es noch andere Schalter, außer jenen, die ich aus sysctl oben veröffentlichte?

Wenn nicht, wenn ich also nicht etwas falsch eingestellt habe, das ausdrücklich das Swappen verhindert, dann nehme ich das für mich und mit FreeBSD als gegeben hin und leite halt meine Schlüsse daraus ab.
Wenn ich aber etwas falsch eingestellt habe, würde ich das natürlich gerne mal ändern und sehen, wie es dann aussieht.
Immerhin besteht diese Möglichkeit, weil ich ja immer ohne SWAP auskommen wollte und möglicherweise da mal eine Optimierung in diese Richtung irgendwo abgeschrieben habe.

Deshalb vermied ich es, die alte Diskussion um SWAP als Grundsatzdiskussion wieder auf zu rühren. Mir fehlen da wirklich die Argumente und das Wissen. Deshalb akzeptiere ich ja auch, wenn Andere mich belehren und erklären, dass SWAP trotzdem einen Sinn macht und deshalb habe ich es nun ja auch mal wieder benutzt (einfach, um das dann auch als mögliche Fehlerquelle auszuschließen und es auch mal nach langer Zeit wieder zu beobachten).
 
Das will ich kurz machen, weil ich da wohl falsch verstanden worden bin.
Das ist gut möglich. :-)

Ohne Hilfe hier im Forum könnte ich FreeBSD gar nicht bewältigen.
Es ist also ziemlich logisch, dass ich bei Fragen und Problemen hier aufschlage.
Ist ja auch alles in Ordnung. Auch das man Dinge ausprobiert usw. Alles fein.

Gibt es noch andere Schalter, außer jenen, die ich aus sysctl oben veröffentlichte?
Also bezüglich Swapping und insbesondere den von Dir angefragt "Swappiness"-Parameter, da ist mir so spontan nix bekannt.

Wenn nicht, wenn ich also nicht etwas falsch eingestellt habe, das ausdrücklich das Swappen verhindert
Also nach dem was ich hier so mitbekommen habe, hast Du diesbezüglich nix verstellt.
Was mich stutzig macht ist, das Du ein "Out-of-Memory"-Fehler kriegst, obwohl ja eigentlich noch genügend Speicher (also RAM + Swap) da sein müsste.
Allerdings hast Du ja bisher auch - trotz Nachfrage - nicht verraten, wer die Fehlermeldung ausgibt und wie sie ganz konkret lautet.

So ne Geschichten wie Swapfreudigkeit oder Tuningmöglichkeiten, da kann man mal so locker flockig drüber fachsimpeln oder auch nicht.
Aber DAS (also diese out-of-memory-Geschichte) deutet möglicherweise auf ein Problem hin. Und dem würde ich dann entsprechend auch Aufmerksamkeit schenken und nicht einfach drüber hinweggehen.

Deshalb vermied ich es, die alte Diskussion um SWAP als Grundsatzdiskussion wieder auf zu rühren. Mir fehlen da wirklich die Argumente und das Wissen.
Es klang erst so, als hättest Du da gute Gründe für, und hattest aber keinen Bock darauf, die mitzuteilen.
 
Also nach dem was ich hier so mitbekommen habe, hast Du diesbezüglich nix verstellt.
Was mich stutzig macht ist, das Du ein "Out-of-Memory"-Fehler kriegst, obwohl ja eigentlich noch genügend Speicher (also RAM + Swap) da sein müsste.
Allerdings hast Du ja bisher auch - trotz Nachfrage - nicht verraten, wer die Fehlermeldung ausgibt und wie sie ganz konkret lautet.
ah, hatte ich nicht beschrieben?
Entschuldigung. Manchmal denkt man...

Also etwa so.
Ich starte eine Win10 VM, der ich (extrem) viel RAM zugewiesen habe und mein RAM ist bereits belegt (nicht wirklich belegt, viel Inact und Wired dabei), aber es ist eben nur ziemlich wenig RAM direkt frei, dafür aber die komplette SWAP.
Dann pausiert die VM und meldet, dass es ein RAM-Problem gibt. Wenn ich weiter laufen lasse (die Pause manuell beende), dann kommt das womöglich mehrfach vor, aber irgendwie setzt sich die VM schließlich durch und läuft. Alles läuft dann ganz hervorragend.
Das scheint mir zu der Aussage vom trägen ARC zu passen, denn den hatte ich da ja noch nicht begrenzt und der machte sich da entsprechend breit.

Nachdem dies aber lief, wollte ich den Klon dieser VM nun aber ebenfalls mal starten. Vollkommen ohne Sinn. Der Klon ist eine Sicherheit zur Sicherheit zum Backup und so weiter, aber ich ziehe ihn halt ebenfalls mit. Und meine Vorstellung war, dass doch nun wirklich mal geswapped werden müsste!
Statt dessen verabschiedete sich mein PC nun aber langsam und schließlich blieb nur der Neustart.
Das verwunderte mich sehr.
Deshalb hier mal nachgefragt.
Kein wirkliches Problem, nicht wichtig.


Nur zur Abklärung:
Der HW-Fehler zeigt sich vollkommen anders. Das ist dies also nicht.
Das heißt, zunächst zeigte er sich eben gar nicht, sondern ich fand den PC am Morgen neu gebootet vor und keine passenden Einträge zu Stromausfällen während der Nacht (was ja bei mir häufiger vorkommen kann). Nach mehrmaligem Ignorieren dann die erste Vermutung: mit dem, was in der Nacht geschieht, ist das System nicht zufrieden. Deshalb dann meine "Pfuscherei" mit SWAP und so. Auch einige sonstige Dienste brachten es nicht, ACPI und Ausschalten des Power-Buttons auch nicht und überhaupt gar nichts. Zuletzt tauschte ich das Netzteil und der PC blieb dann auch über 60 Tage aktiv. Wunderbar? Ja, bis ich mal am Tage (endlich) dies erlebte: Griff zur Maus, Bildschirme plötzlich dunkel und PC startet neu.
Heussa. Der wird nicht erst langsam, da ist nicht groß irgendwelche Temperatur hoch oder irgendwas auffällig, das Biest startet einfach manchmal neu. Manchmal innerhalb von zwei Tagen, manchmal nach mehreren Monaten.
Lästig wie Sau, aber noch nicht so, dass ich wirklich an Ersatz denken will. Dafür geht alles noch zu gut.
Die "Experimente" mit SWAP sind aber quasi ein Ableger dazu.
Denn davor hatte ich eben gar keinen SWAP benutzt und damit auch gar keine Probleme gehabt, nun aber dann ein schlechtes Gewissen bekommen und es eben dann mal mit probieren wollen.
 
Dann pausiert die VM und meldet, dass es ein RAM-Problem gibt.
Noch mal die Frage: Wer meldet das jetzt? VirtualBox? Oder das Windows in der VM oder wie?
Und wie sieht die Meldung ganz konkret aus? (mach ggf. einfach einen Screenshot)
Zusatzfrage: Gibts irgendwie einen zeitnahen Eintrag in der Logdatei /var/log/messages ?

Das scheint mir zu der Aussage vom trägen ARC zu passen
Möglicherweise. Auf der anderen Seite war aber Swap frei. Von daher sollte nicht einfach ein Out-of-Memory kommen.
Wie verhält es sich den mit begrenztem ARC? Tritt da das Problem in ähnlicher Weise auf oder nicht?

Der wird nicht erst langsam, da ist nicht groß irgendwelche Temperatur hoch oder irgendwas auffällig, das Biest startet einfach manchmal neu.
Auch hier wären etwaige Einträge in der /var/log/messages interessant. Wenn da nix drin steht, muss man evtl. noch mal ein bisschen was anschalten.
 
Noch mal die Frage: Wer meldet das jetzt? ViortualBox? Oder das Windows in der VM oder wie?
Und wie sieht die Meldung ganz konkret aus?
da fragst du was, denn dann ist ja mit "normalen" Einstellungen kaum nachvollziehbar, ohne dass der PC dann auch die Grätsche macht.

Die Meldung kommt von VirtualBox, aber nur im Zusammenhang mit dem Start der Win10 VMs.
Wenn ich das recht sehe, belegt etwa eine VM mit einem Ubuntu den RAM nicht sofort, den man dort reserviert. Entsprechend startet dieses Ubuntu problemlos durch, auch dann, wenn weniger RAM vorhanden ist, als von der VM (maximal) gefordert wird.

Die Win10 VMs scheinen aber "vorsorglich" allen Speicher für sich zu beanspruchen, der in der VM als RAM gesetzt ist.
Deshalb räumen sie sich Speicher frei und das kann halt dauern...
Wenn ich den ARC nicht begrenzt habe und dann auch noch einige Tage lang mit dem PC gearbeitet habe, kann das Windows aus der VM offenbar nicht mehr schnell genug Speicher frei räumen und pausiert dann eine Weile, bis man eben die Pause zurück setzt.
VirtualBox scheint nicht gerne auf SWAP zuzugreifen, oder ich weiß nicht, wie man das entsprechend einstellt.

Nun habe ich erst vor kurzem gebootet und der ARC ist auf 16 begrenzt und ich führe zwei Win10 und einen alten Lubuntu in der VM problemlos aus, aber die zweite Win 10 brauchte Minuten zum Starten und "frei räumen" von RAM.
Das werde ich nun ein wenig weiter treiben, aber erst diese Antwort schicken, nicht, dass mir die Puste unter Wegs ausgeht.
 
So wirklich im Detail kann ich nichts dazu sagen, dafür bin ich leider nicht mehr tief genug im Thema drin. Man sollte aber im Hinterkopf haben, dass sich FreeBSDs VM-Subsystem und Swapverhalten über die letzten Hauptreleases stark verändert hat. Vor allem:

  • Anders als Linux macht FreeBSD macht schon seit ich meine 10.0 in Standardeinstellung kein Overcommit mehr. Das heißt, es wird nur Speicherallokationen stattgegeben, die im Moment der Anforderung auch erfüllt werden können. Darauf spekuliert, dass im Moment zwar zu wenig frei ist, in der Zukunft, wenn der Speicher wirklich benötigt wird, aber doch genug frei sein könnte, wird nicht mehr. Das treibt den realen Speicherbedarf plötzlicher, großer Anforderungen hoch. Erhöht aber gleichzeitig die Systemstabilität.
  • Es wird seit 12.0 deutlich defensiver als vorher geswappt. Die Swap kommt erst ins Spiel, wenn tatsächlich kein freier Speicher mehr vorhanden ist
  • FreeBSD macht spätestens seit 13.0 so gut wie ein präventives Swapping mehr. Früher legte FreeBSD Prozesse, die 24 Stunden inaktiv waren, generell in die Swap. Daher sammelten FreeBSD-Systeme mit steigender Uptime Swapbelegung an. Inzwischen wird er geswappt, wenn es notwendig ist. Das bringt mit sich, dass FreeBSD besser ganz ohne Swap klarkommt.

Als freier Speicher werden gezählt:
  • Freier, direkt nutzbarer Speicher. Das ist der Wert Free im top.
  • Speicher der gerade wieder nutzbar gemacht wird, der Wert Laundry.
  • Ungenutzer, aber noch nicht wieder nutzbar gemachter Speicher. Der Wert Inact.
  • Caches. Im top sind das Buf und der ZFS ARC, welcher in Wired mit eingeht.

Wenn plötzlich große Mengen Speicher zur Verfügung gestellt werden müssen, muss ZFS seinen ARC freiräumen. Anschließend muss der Speicher durch die Laundry und danach steht er zur Verfügung. Das ist meist immer noch deutlich schneller als aktiven Speicher in die Swap zu drücken.
 
Also meiner schwappt ganz ordentlich:
Code:
Mem: 14G Active, 8689M Inact, 6785M Laundry, 16G Wired, 789M Buf, 1337M Free
ARC: 9090M Total, 4569M MFU, 2493M MRU, 6643K Anon, 496M Header, 1526M Other
     5747M Compressed, 19G Uncompressed, 3.46:1 Ratio
Swap: 40G Total, 7450M Used, 33G Free, 18% Inuse, 28K In

  PID USERNAME    THR PRI NICE   SIZE    RES STATE    C   TIME    WCPU COMMAND
72225 root         34 134  i10    23G    15G kqread  18 137.0H 1577.93% bhyve
 
Also meiner schwappt ganz ordentlich:
Danke für die Rückmeldung.
Vielleicht hatte ich mich mal wieder unsauber ausgedrückt.
Das passiert bei mir auch, nämlich dann, wenn ich SWAP benutze und der PC einige Zeit am Stück läuft, also wenigstens einige Tage.
Nun wollte ich einen akut eingerichteten SWAP testen also den PC dazu bringen, den SWAP auch zu nutzen und startete deshalb mehrere Speicher-Intensive Anwendungen.
Als ich meinen Beitrag schrieb, hatte ich nur wenige Anwendungen probiert und statt zu swappen, wurden mir die Windows-VMs blockiert. Das konnte ich irgendwie nicht zusammen bringen.
Später schaffte ich es dann auch mit vielen anderen Anwendungen, den SWAP zart anzufassen, also ganz wenige GB SWAP wurden dann belegt.

Wie auch immer, selbst mit diesen eher verzweifelten Versuchen kann ich bisher keine Möglichkeit finden, den Fehler meines PCs bewusst zu reproduzieren. Die Laufzeit schwankt mit allen bisherigen Maßnahmen vollkommen willkürlich zwischen einem Tag und zwei Monaten.
Das ist ein echt mieser Fehler und nachdem ich das Netzteil getauscht hatte und erst mal mehrere Wochen Ruhe war, hatte ich irgendwie schon Hoffnung, aber dann in einer Woche wieder drei Ausfälle, vollkommen spontan und nicht zu greifen.
Wahrscheinlich Zeit für einen umfassenden HW-Tausch. Wenn ich mal wieder Zeit habe, mich darum zu kümmern und meine Wünsche wachsen zu lassen...
 
Danke für die Rückmeldung.
Vielleicht hatte ich mich mal wieder unsauber ausgedrückt.
Das passiert bei mir auch, nämlich dann, wenn ich SWAP benutze und der PC einige Zeit am Stück läuft, also wenigstens einige Tage.
Nun wollte ich einen akut eingerichteten SWAP testen also den PC dazu bringen, den SWAP auch zu nutzen und startete deshalb mehrere Speicher-Intensive Anwendungen.
Als ich meinen Beitrag schrieb, hatte ich nur wenige Anwendungen probiert und statt zu swappen,
Hach, das ist normal, das geht nicht. Er schwappt nie so wie man will, sondern irgendwie eigenintelligent.
wurden mir die Windows-VMs blockiert. Das konnte ich irgendwie nicht zusammen bringen.
Ich weiss nicht wie windows seinen speicher handhabt - und schon gar nicht, wo man da was drehen kann.
FreeBSD bhyves macht gelegentlich der oom-killer kaputt.

Wie auch immer, selbst mit diesen eher verzweifelten Versuchen kann ich bisher keine Möglichkeit finden, den Fehler meines PCs bewusst zu reproduzieren. Die Laufzeit schwankt mit allen bisherigen Maßnahmen vollkommen willkürlich zwischen einem Tag und zwei Monaten.
Bäh, das ist ekelhaft. Kann im grunde alles sein, netzteil, memory, schlechtgelaunte Kondensatoren...
 
Zurück
Oben