ZFS Speicherbedarf

h^2

h^2

hat ne Keule +1
Ich habe in meinem Homeserver, der Hauptsächlich als Fileserver dient, 4GiB RAM, bin jetzt nach ein bisschen IO über NFS doch aber an die Grenzen gekommen, so dass mehrere Dienste abgeschossen wurden, u.A. openvpn, was nicht gut ist.

Überhaupt scheint ZFS erst wieder Speicher freizugeben, wenn nurnoch 200MB frei sind, und dann auch immer nur in sehr kleinen Häppchen. Das war anscheinend vorhin nicht schnell genug, wobei auch nur ein Client eine große Datei geschrieben hat.

Was ich außerdem seltsam finde ist, dass sich eigentlich ZFS ja nur RAM_MAX-1GB reservieren soll[1], bei mir aber viel mehr nimmt. Ich habe ein vfs.zfs.arc_max von ca. 2.5GiB, trotzdem zeigt der Speicherverbrauch:
Code: 
Mem: 4108K Active, 27M Inact, 3215M Wired, 5356K Cache, 82M Buf, 290M Free

Der Wired-Anteil dürfte zu mindestens 90% ZFS sein...


[1] laut Best-Practice-Guide von Solaris
 
Solche Beobachtungen wurden auch auf current@ gemacht. Da hat sogar einer behauptet, dass Speicherallokation im Kernel wegen ZFS klemmte (write-Aufruf hat "out of memory" geschmissen). Und das ist sogar eine Deadlock-Gefahr.

Nur zur Info:

Ich habe hier 6GB Speicher und zur Zeit keine Probleme mit ZFS, obwohl es sauschnell ist. Gestern ist mir der Kiefer runtergeklappt als mkisofs für das Bauen einer DVD (3,8 GB) nur ein Paar Sekunden gebraucht hat (also im Cache war da nichts; read-ahead plus write-cache?). Hab ZFS schon seit mehr als einem Jahr, aber dieses Verhalten war mir neu. ZFS ist auch das erste Softraid, das tatsächlich beim Lesen schneller ist als eine Einzelplatte (das wusste ich aber auch schon vorher).
 
ZFS nutzt unter FreeBSD ein anderes Speichermodell als unter Solaris. Seit 8.2 ist "Back Pressuring" implementiert, d.h. es füllt erst einmal einen Großteil des verhandenen RAM auf. Sobald dieser andersweitig benötigt wird, beginnt es ihn wieder freizugeben. Allerdings ist dies System in meinen Augen für Fälle, wo ZFS nicht exklusiv auf der Maschine läuft, zu träge. Ich konnte es öfter beobachten, dass Anwendungen in die Swap gedrückt wurden und ZFS erst hinterher den Speicher freiräumte. Dazu kommt, dass ZFS prinzipbedingt zu Speicherfragmentierung führt, die sich in den von nakal genannten "out of memory"-Meldungen und Deadlocks äußern können. Zwar besitzt es inzwischen eine Menge Magie um in diesen Fällen Crashs zu verhindern, in Extremfällen können sie aber dennoch eintreten. Lange Rede, kurzer Sinn: Wenn ZFS nicht allein auf einer Maschine ist, kann das manuelle Begrenzen des ARC sinnvoll sein. Allerdings sollte man die Faustformel "Ein Gigabyte RAM pro ein Terabyte Speicherplatz" nicht unterschreiten, wenn möglich sogar großzügig über ihr bleiben. Andernfalls handelt man sich neue Probleme ein, darunter u.a. miserable Performance.

Zu NFS ist noch zu sagen, dass die meisten Implementierungen versuchen die POSIX-Konsistenzeigenschaften auch über das Netzwerk zu garantieren. Daher schicken sie nach jeder Operation ein "sync" an das zugrunde liegende Dateisystem. Daher kann hohe ZFS-Last dazu führen, dass die ZIL (im weiteren Sinne ein Journal) überlastet wird und die Performance drastisch einbricht. In diesem Fall bietet es sich an, die ZIL auf ein separates und sehr schnelles Medium wie z.B. eine SLC-SSD auszulagern. Man kann sie auch abschalten, dadurch erhält ZFS aber eine Art "Lag". D.h. nach einer Katastrophe ist das Dateisystem zwar konsistent, es fehlen aber die letzten Operationen.
 
Yamagi schrieb:
ZFS nutzt unter FreeBSD ein anderes Speichermodell als unter Solaris. Seit 8.2 ist "Back Pressuring" implementiert, d.h. es füllt erst einmal einen Großteil des verhandenen RAM auf. Sobald dieser andersweitig benötigt wird, beginnt es ihn wieder freizugeben. Allerdings ist dies System in meinen Augen für Fälle, wo ZFS nicht exklusiv auf der Maschine läuft, zu träge. Ich konnte es öfter beobachten, dass Anwendungen in die Swap gedrückt wurden und ZFS erst hinterher den Speicher freiräumte. Dazu kommt, dass ZFS prinzipbedingt zu Speicherfragmentierung führt, die sich in den von nakal genannten "out of memory"-Meldungen und Deadlocks äußern können. Zwar besitzt es inzwischen eine Menge Magie um in diesen Fällen Crashs zu verhindern, in Extremfällen können sie aber dennoch eintreten. Lange Rede, kurzer Sinn: Wenn ZFS nicht allein auf einer Maschine ist, kann das manuelle Begrenzen des ARC sinnvoll sein. Allerdings sollte man die Faustformel "Ein Gigabyte RAM pro ein Terabyte Speicherplatz" nicht unterschreiten, wenn möglich sogar großzügig über ihr bleiben. Andernfalls handelt man sich neue Probleme ein, darunter u.a. miserable Performance.
Zum Vergrößern anklicken....
Ich habe ja auch nur 2TB, da sollten 3GB RAM doch reichen, der Rest kommt mit einem GB aus. Aber jetzt nochmal konkret, wenn das arc_max auf 2.5GB eingestellt ist, wie kann es dann sein, dass 3.x GB von ZFS beansprucht werden?

Zu NFS ist noch zu sagen, dass die meisten Implementierungen versuchen die POSIX-Konsistenzeigenschaften auch über das Netzwerk zu garantieren. Daher schicken sie nach jeder Operation ein "sync" an das zugrunde liegende Dateisystem. Daher kann hohe ZFS-Last dazu führen, dass die ZIL (im weiteren Sinne ein Journal) überlastet wird und die Performance drastisch einbricht. In diesem Fall bietet es sich an, die ZIL auf ein separates und sehr schnelles Medium wie z.B. eine SLC-SSD auszulagern. Man kann sie auch abschalten, dadurch erhält ZFS aber eine Art "Lag". D.h. nach einer Katastrophe ist das Dateisystem zwar konsistent, es fehlen aber die letzten Operationen.
Zum Vergrößern anklicken....

Ja, das habe ich auch schon gelesen. Auch wenn die Daten nicht ultra-kritisch sind, hört sich das aber nicht nach einer vernünftigen Lösung an. Ich betreibe ja extra einen Fileserver mit RAID um Risiko von Datenverlust zu reduzieren. Auch weil der Desktop eher mal hängenbleibt mit Xorg und weiß ich nicht. Da will ich ja dann nicht, dass bei einem CLient-Crash die Daten im Æther verschwinden, wenn sie hätten geschrieben werden können...
 
h^2 schrieb:
Ich habe ja auch nur 2TB, da sollten 3GB RAM doch reichen, der Rest kommt mit einem GB aus. Aber jetzt nochmal konkret, wenn das arc_max auf 2.5GB eingestellt ist, wie kann es dann sein, dass 3.x GB von ZFS beansprucht werden?
Zum Vergrößern anklicken....

Benutzt du L2ARC? Also extra noch Platten als weiteren Cache?

Rob
 
Ich habe mir jetzt einfach gedacht "investier 20€ in RAM, statt 20h Zeit und Nerven" und auf 8GB aufgestockt. Schwupps geht der Wired-Wert direkt auf ~7GB, was auch über dem arc_max liegt. Ich habe jetzt mal einen wesentlich kleineren arc_max gesetzt, undzwar 5GB. Mal gucken ob sich dran hält...
 
Installiere dir mal aus den ports "zfs-stats" ... sind die ZFS Sachen schön aufgelistet ... dann mal zfs-stats -A

Ich doktore damit auch seit ner weile rum ... sehr kömisch mit dem wired Space ... minimiere ich kern.maxvnodes und setze es dann wieder höher, wird wieder RAM freigegeben z.b.

Grüße
Kai
 
Also, ich habe den arc_max jetzt auf 5368709120 gesetzt. top -Sa sagt aber trotzdem 7068M Wired.

Folgendes sagen die stats:
Code: 
------------------------------------------------------------------------
ZFS Subsystem Report                            Sun Nov  6 21:19:53 2011
------------------------------------------------------------------------
ARC Misc:
        Deleted:                                63236
        Recycle Misses:                         515621
        Mutex Misses:                           46
        Evict Skips:                            46

ARC Size:
        Current Size (arcsize):         100.00% 5119.89M
        Target Size (Adaptive, c):      100.00% 5120.00M
        Min Size (Hard Limit, c_min):   12.50%  640.00M
        Max Size (High Water, c_max):   ~8:1    5120.00M

ARC Size Breakdown:
        Recently Used Cache Size (p):   60.66%  3105.74M
        Freq. Used Cache Size (c-p):    39.34%  2014.26M

ARC Hash Breakdown:
        Elements Max:                           462936
        Elements Current:               99.94%  462661
        Collisions:                             658605
        Chain Max:                              14
        Chains:                                 114576

ARC Eviction Statistics:
        Evicts Total:                           17862298624
        Evicts Eligible for L2:         94.84%  16940350464
        Evicts Ineligible for L2:       5.16%   921948160
        Evicts Cached to L2:                    0

ARC Efficiency:
        Cache Access Total:                     28853860
        Cache Hit Ratio:                95.21%  27470656
        Cache Miss Ratio:               4.79%   1383204
        Actual Hit Ratio:               48.66%  14041179

        Data Demand Efficiency:         97.41%
        Data Prefetch Efficiency:       65.04%

        CACHE HITS BY CACHE LIST:
          Anonymously Used:             45.74%  12565181
          Most Recently Used (mru):     11.39%  3128874
          Most Frequently Used (mfu):   39.72%  10912305
          MRU Ghost (mru_ghost):        1.47%   405019
          MFU Ghost (mfu_ghost):        1.67%   459277

        CACHE HITS BY DATA TYPE:
          Demand Data:                  4.82%   1325391
          Prefetch Data:                0.68%   187734
          Demand Metadata:              45.95%  12621902
          Prefetch Metadata:            48.54%  13335629

        CACHE MISSES BY DATA TYPE:
          Demand Data:                  2.54%   35193
          Prefetch Data:                7.30%   100917
          Demand Metadata:              74.90%  1036082
          Prefetch Metadata:            15.26%  211012
------------------------------------------------------------------------
Das sagt mir doch, der arc sei garnicht größer als er sein soll. Was versteckt sich dann hinter dem wired?
 
Hm, das ist ja mäßig schlecht. Also leakt irgendwo irgendwas und ohne viel Frickelei find ich nicht raus was es ist :|
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben