ZFS und Beasty – ein erster Erfahrungsbericht

Posted by Jesco Freund at June 28, 2008 9:35 a.m.

Da ich schon mehrfach darauf angesprochen wurde, gibt es heute einen kurzen Erfahrungsbericht zum Einsatz von ZFS unter FreeBSD – sozusagen nach dem ersten verflixten Monat Um eines gleich vorweg zu nehmen: Mein Server ist kein Hochlast-System, das permanent unter Dauerfeuer steht. Die Load bleibt meist deutlich < 1, und allzu umfangreich sind die Schreib-/Lese-Aktivitäten auf den ZFS Datasets auch nicht (wenn man vom allnächtlichen Backup einmal absieht). Von daher werden sich meine Erfahrungen wohl nur bedingt auf andere Systeme übertragen lassen.

Trotz des meist eher gemütlichen Betriebszustandes hat ZFS es aber in der Anfangsphase einige Male geschafft, den Kernel in die Panic zu treiben. Im Log finden sich dann solche Hinweise:

savecore: reboot after panic: kmem_malloc(90112): kmem_map too small: 335228928 total allocated

Das Problem als solches ist nicht unbekannt: FreeBSD stellt für malloc(9)-Aufrufe des Kernels per default nur einen relativ kleinen Adressbereich zur Verfügung, so dass der Kernel nur ~300MB RAM adressieren kann. Für ZFS ist das deutlich zu wenig, wenn man seinen Speicherhunger nicht deutlich in seine Schranken weist (was natürlich zu Lasten der Performance geht).

Wer ZFS unter FreeBSD betreiben möchte, dem bleibt also derzeit nichts anderes übrig, als an den Parametern für die Adressraum-Zuteilung zu drehen. Mit meinen 2 GB RAM habe ich eine relativ komfortable Ausgangslage. Durch options KVA_PAGES=512 in meiner Kernel-Konfiguration konnte ich den 32-Bit Adressraum so aufteilen, dass sowohl Kernel als auch Userspace nahezu 100% des gesamten physisch verfügbaren Speichers adressieren können. Natürlich möchte ich nicht, dass der Kernel sich den gesamten verfügbaren Speicher unter den Nagel reißt, daher habe ich das auf die Hälfte begrenzt (Einträge für /boot/loader.conf):

vm.kmem_size="1024M"
vm.kmem_size_max="1024M"

Außerdem habe ich ZFS etwas die Flügel gestutzt:

vfs.zfs.arc_max="160M"
vfs.zfs.vdev.cache.size="5M"

Wichtig zu wissen: Der Adaptive Replacement Cache (ARC) wird von einem multithreaded Prozess gesteuert. Wird von einem dieser Threads neuer Speicher angefordert, wird dieser auch allokiert, unabhängig davon, ob die Maximalvorgabe bereits erreicht oder überschritten wurde. Einer der Threads ist im Gegenzug dafür zuständig, wieder Speicher freizugeben, wenn die erlaubte Obergrenze erreicht wird. Dadurch kann der vorgegebene Maximalwert aber kurzfristig um ein Vielfaches überschritten werden, so dass hier ein Wert deutlich unterhalb des maximal durch Kernelprozesse allokierbaren Speichers zu empfehlen ist. So besteht wenigstens die Chance, dass der Aufräum-Thread rechtzeitig aktiv wird, bevor es zu einer katastrophalen Situation – sprich: Panic – kommt.

Unabhängig von diesen kleineren (weil mittlerweile gut dokumentierten) Unannehmlichkeiten hat sich ZFS bei mir als äußerst robust erwiesen. Keiner der Panic-bedingten Abstürze hatte irgendwelche Inkonsistenzen zur Folge (UFS ist da anfälliger), und auch über die Performance lässt sich nichts negatives berichten. Über die Robustheit lässt sich aber mit Sicherheit erst mehr sagen, wenn ein wenig mehr Zeit als nur der verflixte erste Monat vergangen ist… vielleicht nach dem ersten verflixten Jahr?

No comments | Defined tags for this entry: FreeBSD, ZFS

Comments

No comments