rsnc bleibt mit "out of swap" stehen...

[kira12]

Hallo Leute,

ich nutze die 9.0_x64 und 10Gb Ram mit einigen ZFS Laufwerken, leider ist auch das swap Laufwerk auf einem ZFS Device. Kann ich das Problem mit vm.kmem_size_max="xx" und vfs.zfs.arc_max="xx" verhindern? Welche Werte sind dafür sinnvoll bei 10Gb Ram? Meine ZFS-Laufwerke sind 36GB, 5TB und 2TB groß, swap ist 11Gb.

Gruß ré

[Crest]

Ich gehe mal davon aus das rsnc rsync heissen soll. Mit 1,2GiB RAM würde ich einfach kein ZFS nutzen oder mal auf mindestens 4 GiB (besser 8GiB) RAM aufrüsten.

[cla]

Er hat aber schon 10 GB RAM.

Und ich dachte das Problem mit dem Swap sei irgendwie schon gefixt...kommt das mit 9.1? Oder täusch ich mich da?

[Crest]

Ich habe auf meinem Desktop 2*sizeof(RAM) als ZVOL angelegt unter 9.0 und mit 16GiB RAM noch nie Probleme dieser Art bekommen auch nicht als ich ein tmpfs vollgeschrieben habe oder versucht habe 40GiB in einem Prozess zu halten.

[Yamagi]

Also, es gab mehrere Runden, in denen das Speichermanagement von ZFS verbessert wurde. Der letzte große, ultimative Umbau kam mit 9.0. Ein Teil davon ist in 8.3 zurückgeflossen. Spätestens mit 9.0 sollte ZFS nun ohne größere Speicherprobleme laufen (sofern man genügend RAM hat) und tatsächlich gibt es auf der Mailingliste praktisch keine Berichte über Speicherprobleme mit ZFS mehr. Zwischen 9.0 und 9.1 haben sich am ZFS nur kleinere Bugfixes ergeben, aber nichts was für den gemeinen Nutzer nun absolut kritisch wäre. Außerdem wurde die Unterstützung für "Feature Flags" eingefügt, um mit Illumos kompatibel zu bleiben.

Zu dem konkreten Problem: Frühe ZFS-Versionen hatten das Problem, dass das Schreiben in ein ZVOL RAM benötigte. Eine Swap auf dem ZVOL führte also dazu, dass das Schreiben der Swap RAM benötigte, wodurch mehr geswappt werden musste... Bis der Hahn zu war. In aktuellen ZFS-Versionen greift da das Back Pressuring, d.h. ZFS erkennt dass nur noch wenig RAM vorhanden ist und krallt sich auf Kosten der Performance keinen Neuen. Deshalb sind Swaps auf ZVOLs nun möglich, wobei man in solche Swaps jedoch nicht dumpen kann!
rsync und ZFS waren noch nie gute Freunde. In der Vergangenheit konnte man praktisch jedes Speicherproblem bei ZFS durch rsync auslösen. Das liegt wohl in den Zugriffsmustern von rsync begraben. Grundsätzlich gilt: ZFS schaufelt so viel RAM frei, wie er kann. Aber irgendwo ist halt die Grenze. Zudem benötigt rsync gerade bei großen Mengen Dateien extrem viel RAM!. Der beste Tipp für dich wäre also "Mehr RAM!", gefolgt von "Mehr Swap!", gefolgt von "Andere Verzeichnisstruktur". Mit "gigasync" gibt es auch noch ein kleines Perl-Tool, was in solchen Fällen helfen kann...

An der kmem_map rumzudrehen, ist unter amd64 übrigens völlig sinnlos. Die ist bereits so extrem groß, >300 Gigabyte, dass ein Erhöhen nichts mehr ändert. Und dir gehen ja auch nicht der Kernelspeicher oder sogar die virtuellen Adressen aus, stattdessen hat ein Userland-Prozess schlicht und ergreifend keinen Speicher mehr. Eine Möglichkeit wäre noch, dass der Prozess in ein Limit läuft, aber dann müsste die Fehlermeldung anders lauten... Und sei froh, dass es kein Linux ist. Das schießt wahllos Prozesse ab, manchmal auch init (oder wie es im Moment gerade heißt).

[kira12]

Hallo Leute,

danke für eure sehr informative Hilfe. Ich hatte das Zpool-install nur gewählt weil ich die gmirror variante nicht hinbekommen habe. Ich werde nach dem Schema des Zpoolinstall noch mal versuchen das auf gmirror umzusetzen.
Aber letztendlich habe ich gelernt wie wichtig Swap ist. Ich werde eine eigenen Platte für Swap benutzten. Da ich für das OS immer 36GB SCSI Platten nehme dürfte da eine ideal sein für Swap.

Gruß ré

[pit234a]

wieso ich nicht einfach still halten kann, weiß ich nicht. Denkt also nicht: "schon wieder!", sondern lest es einfach nicht, wenn es euch bereits bekannt ist.
Aber, sooo einfach sehe ich das nicht und generell zu behaupten, viel RAM, viel SWAP dann kann nichts schief gehen, ist mir einfach zu einfach.
Natürlich: wer denn den Platz hat und ausreichend RAM, der macht damit keinen Fehler, da stimme ich voll zu.

Das Problem, das hier geschildert wird, tritt aber dadurch auf, dass überhaupt SWAP genutzt wird und zwar präziser, SWAP auf einem ZFS.
Ich halte nach wie vor ZFS für eine Super Sache, hauptsächlich für Daten-Archive und Raids.
Ich verstehe nach wie vor nicht, weshalb UFS nicht ausreicht, wenn es um System und/oder SWAP geht.
Eine ganze Reihe von diesen Problemen im Zusammenhang mit ZFS kämen doch gar nicht auf, wenn das System ganz gewöhnlich auf einem UFS-Dateisystem liegen würde und lediglich die Bereiche, auf denen man Daten hält, ZFS und Zpools nutzen.

Also, wenn mich die Umstände nicht zwingen, und genau genommen sehe ich nicht, wodurch ich da überhaupt gezwungen werden sollte, dann installiere ich auf UFS und habe keine Probleme.

Mein Fileserver läuft immer noch auf 7.4 und hat deshalb ein ziemlich altes ZFS für die Festplatten, die ich zu einem Pool zusammen gefasst habe. Der Rechner hat 4GB RAM und keinen SWAP. Das System läuft von einem USB-Stick in UFS, wobei ich einige Verzeichnisse ins tmpfs und einige auf den Zpool ausgelagert habe, um den Schreibverkehr zum Stick während des Betriebes zu minimieren. Der Server läuft 24x7 und wird nur bei Stromausfall (das haben wir häufiger) neu gestartet. Eine Uptime von 100 Tagen ist eher die Regel, denn die Ausnahme. Es gibt da keine Fehler. Der Server ist auch nur mit seinen Diensten beschäftigt und rechnet nicht noch großartig herum.
rsync nutze ich, allerdings nicht als Server-Client Modell sondern indem ich es auf die NFS gemounteten Verzeichnisse anwende, also quasi local, als besseres cp sozusagen. Dabei passiert auch überhaupt nichts merkwürdiges, weil es ja NFS ist, worüber der Zugriff läuft.

Also, gerade, wenn du mehrere Platten hast und dabei eine 36GB benutzen willst, dann nimm doch UFS dafür und setze dein System darauf und Ruh ist.

[kira12]

Hallo Pit,

ich gebe dir zu 100% recht. Ich habe bis jetzt ZFS nur für Datenlaufwerke benutzt. Für das OS hatte ich immer UFS per Hardware Raid1 auf 2x36GB SCSI Platten. Da nun mein Hardwarecontroller die beiden Platten kurz hintereinander als Feherhaft markiert hatte wollte ich gern Softwareraid per Label/gmirror nutzen. Irgendwie habe ich das nicht hinbekommen und darum ein ZFS Bootmedium erzeugt. Das war nur ein Test und ich habe schnell erkannt das die Kombination SWAP auf ZFS schlecht ist. Aber das war sehr lehrreich für mich :-)

Gruß ré

[Crest]

Entweder würde ich einen gmirror als Swap verwenden oder gar kein Swap und dafür genug RAM.

[Lord_x]

Ich kenne das Problem nur vom hören anderer. Sinnvoll ist sicherlich noch folgende Einstellung:

zfs set checksum=off tank/swap

[Yamagi]

Dann verliert man aber den größten Vorteil von ZFS: Die integrierte Konsistenzprüfung.

[oenone]

Zitat von Yamagi

Dann verliert man aber den größten Vorteil von ZFS: Die integrierte Konsistenzprüfung.

Macht das bei Swap was aus?

[Yamagi]

Ich würde sagen: Ja. Denn was bringt mit der tolle ECC-RAM, wenn die Swap Inkonsistenten einstreuen kann?