ZFS Speicheroptimierung

J

joergpc

Well-Known Member
Hallo an alle,

meine Frage und Rundfrage an alle ZFS Nutzer,

wieviel vm.kmem_size Teilt ihr dem System mit

z. b. bei 768 MB
vm.kmem_size="330M"
vm.kmem_size_max="330M"
vfs.zfs.arc_max="40M"
vfs.zfs.vdev.cache.size="5M"

ich verwendere gerade ein System mit 32 GB

ohne expilizite zuweisung nimmt sich das System

30 GB vm.kmem_size

und ich weise -> vfs.zfs.arc_max="24576M"/vfs.zfs.vdev.cache.size="160M" zu,
könnte man auch mehr oder macht es sinn weniger.

Was sind eure erfahrungen damit und Stabilität kommt immer vor Performance.

joergpc

;) ZFS Liebhaber
 
Also, eigentlich macht ZFS es von sich aus richtig. Wenn die Kiste allerdings noch andere Dinge machen soll als nur Fileserver zu spielen, kann es helfen dem VM etwas unter die Arme zu greifen und ZFS auf etwa Zweidrittel des RAMs zu begrenzen:
Code: 
vfs.zfs.arc_max="24G"
Alles andere ist tendenziell eher schädlich. Gerade sysctl wie "vm.kmem_size" sollte man wirklich nur dann verwenden, wenn man wirklich verstanden hat, was sie machen. Die Defaults sind gut, an ihnen rumzudrehen kann sehr viel Ärger machen...
 
joergpc: Meine Erfahrung ist seit FreeBSD 8.2 die Finger von den Sysctls zu lassen. Mit FreeBSD 9.0 und 9.1 wurde das VM Subsystem noch mal etwas verbessert. Solange du nicht oft mehrere GiB RAM auf einen Schlag allozieren willst lass die FInger von den Sysctls. ZFS gibt den Speicher schon frei, wenn es ne bessere Verwendung dafür gibt.
 
Hallo Danke für eure Antworten,

auf dem System Freebsd 9.1 läuft Samba, NFS, iSCSI, CAM (FC) mit gmultipath.

Macht es da sinn:

vfs.zfs.vdev.cache.size
vfs.zfs.arc_max

zu setzen oder soll man das dem System überlassen.

Viele Grüße

joergpc

ZFS Liebhaber
 
Bei mir hat letztens der Fileserver unter Load sowohl RAM gefressen, dass er rpcbind abgeschossen hat, was für einen Fileserver echt murks ist. Und der served nur einen 2x2TB Mirror, hat 8GiB RAM und macht sonst eigentlich nichts... :(
Werde den arc_max auf jeden Fall mal runtersetzen. Hoffe das bringt was, unter 8.x hatte ich das schonmal versucht, aber er hatte es einfach ignoriert.
 
im Moment arbeitet das System mit 30 SAS und 30 SATA über
FC und bisher hatte ich keine Stabilitäts Probleme.
 
zudem wundert mich die Standarteinstellung von

vfs.zfs.l2arc_write_boost=8388608
vfs.zfs.l2arc_write_max=8388608

was ja 8 MB entspricht, nicht gerade viel
wenn man bedenkt das die SSDs locker 300 MB und
viel mehr schreiben können.

Gruss

Joergpc
 
ja, die Standard sind dort recht niedrig. Der Grund ist, dass der L2ARC in erster Linie ein lesender Cache ist. Ist das System aufgewärmt, sind etwa 90% der Lese-Anfragen Cache-Hits, schlagen also gar nicht mehr auf das eigentliche Storage durch. ZFS dupliziert nun aber jede Schreib-Anfrage von den Platten auf den L2ARC, damit dieser aktuell bleibt. Der L2ARC wird also doppelt belastet, er soll einmal möglichst viel Bandbreite zum Lesen bereitstellen, möglichst deutlich mehr als das womöglich riesige Platten-Array aus >24 Laufwerken darunter. Gleichzeitig muss er aber auch Schreib-Anfragen bearbeiten, die Lese-Bandbreite kosten. Man benachteiligt also schreibende Operationen auf den L2ARC, um mehr Bandbreite für lesende Operationen zu haben. Da man meist deutlich mehr liest als schreibt, ist das eine durchaus gute Entscheidung.

Nun haben wir aber SSDs zur Verfügung und zumindest im kleinen Bereich sind inzwischen auch billige SSDs deutlich schneller als größere Platten-Arrays und können zudem sehr gut parallel lesen und schreiben. Wenn du also zu viele Cache-Missis siehst, da der L2ARC mit seinen Aktualisierungen nicht hinterher kommt, ist es eine gute Idee vfs.zfs.l2arc_write_max bis zu dem Punkt hochzusetzen, an dem die Lese-Geschwindigkeit einbricht. vfs.zfs.l2arc_write_boost ist ein Sonderfall für die zeit zwischen dem Start des Systems und dem Erreichen einer nutzbaren Füllung des Caches. Gerade bei Systemen, die nur wenig Last haben und daher Tage brauchen bis der L2ARC warm genug ist um Wirkung zu zeigen, kann es sich lohnen diesen Wert drastisch zu erhöhen, um den Cache schneller zu füllen. Auf der Illumos ZFS-Liste wird derzeit übrigens ein Patch diskutiert, der den L2ARC persistent macht. Er müsste damit nicht mehr neu gefüllt werden, wenn das System neugestartet wurde.

Der L2ARC wird mit Daten im ARC verwaltet. Das ist vielen nicht bekannt, aber durchaus wichtig. Denn jedes Megabyte L2ARC verbraucht daher effektiv Speicher im ARC, schränkt den für ZFS zum Cachen nutzbaren RAM damit ein. Je nach Workload kann ein L2ARC daher sogar die Performance senken, da auch die schnellsten SSD deutlich langsamer als RAM sind. Insgesamt bleibe ich dabei, was ich oben schrieb: Beginne mit einem Pool ohne Extras in Standardeinstellung. Mache dir Gedanken, ob Dinge wie ZIL oder L2ARC in deinem Szenario schaden oder nützen. ZIL-Devices nützen meist, L2ARC oft nur in gewissen Grenzen. Nachdem du sie in den Pool eingefügt hast, lasse es einige Tage laufen. Dann analysiere und erst wenn konkrete Performance-Probleme auftreten, beginne zu tunen. Sehr oft wird das nicht notwendig sein.

EDIT: Bei der Analyse von Problemen kann "zfs-stats" sehr helfen. Das ist ein Script, was die chaotischen Sysctl-Performanceindikatoren in ein für Menschen einfacher zu verstehendes Format übersetzt. Bevor man es anwendet, muss man dem System aber einigen Stunden bis Tage Zeit geben sich warmzulaufen. Sonst sagen die Statistiken nichts aus. - http://www.freshports.org/sysutils/zfs-stats/
 
Zuletzt bearbeitet:
Ich möchte mich hier mal noch einmischen in diese Diskussion. Und zwar habe ich hier einen grossen Server stehen mit FreeBSD 9.1 und ZFS mit ca. 16TB. Auf dem Server läuft Samba 3.6 und ca. 1.5TB sind belegt mit sehr vielen einzelnen Dateien.

Einzig eine SSD als Cache für den Pool wurde hinzugefügt. Hier mal eine Statistik über den Cache von einem Server der schon länger läuft:

Code: 
------------------------------------------------------------------------
ZFS Subsystem Report                            Wed May 15 08:46:11 2013
------------------------------------------------------------------------

L2 ARC Summary: (HEALTHY)
        Passed Headroom:                        346.38m
        Tried Lock Failures:                    9.82m
        IO In Progress:                         168
        Low Memory Aborts:                      12
        Free on Write:                          9.88k
        Writes While Full:                      33.52k
        R/W Clashes:                            571
        Bad Checksums:                          0
        IO Errors:                              0
        SPA Mismatch:                           165.31b

L2 ARC Size: (Adaptive)                         111.73  GiB
        Header Size:                    0.15%   170.01  MiB

L2 ARC Evicts:
        Lock Retries:                           40
        Upon Reading:                           7

L2 ARC Breakdown:                               11.24m
        Hit Ratio:                      51.00%  5.73m
        Miss Ratio:                     49.00%  5.51m
        Feeds:                                  5.52m

L2 ARC Buffer:
        Bytes Scanned:                          5.27    PiB
        Buffer Iterations:                      5.52m
        List Iterations:                        352.87m
        NULL List Iterations:                   27.27k

L2 ARC Writes:
        Writes Sent:                    100.00% 65.81k

------------------------------------------------------------------------
------------------------------------------------------------------------
ZFS Subsystem Report                            Wed May 15 09:01:49 2013
------------------------------------------------------------------------

ARC Summary: (HEALTHY)
        Memory Throttle Count:                  0

ARC Misc:
        Deleted:                                8.01m
        Recycle Misses:                         838.08k
        Mutex Misses:                           36.10k
        Evict Skips:                            432

ARC Size:                               84.88%  25.43   GiB
        Target Size: (Adaptive)         84.89%  25.43   GiB
        Min Size (Hard Limit):          12.50%  3.74    GiB
        Max Size (High Water):          8:1     29.95   GiB

ARC Size Breakdown:
        Recently Used Cache Size:       40.98%  10.42   GiB
        Frequently Used Cache Size:     59.02%  15.01   GiB

ARC Hash Breakdown:
        Elements Max:                           1.84m
        Elements Current:               97.76%  1.80m
        Collisions:                             24.61m
        Chain Max:                              19
        Chains:                                 447.27k

------------------------------------------------------------------------

Wenn ich das richtig verstehe, dann wird hier der Cache von ca. 110GB gerade mal zu 25GB verwaltet. Weiter werden schlussendlich nur "11.24m" verwendet! (??)

Das sollen nur Beispiel Daten sein, welche ich hier von einem System kopiert habe.
 
Erstmal super danke für eure rege Teilnahme und die Super Erklärung von
Yamagi.

Wäre es nicht Super und ich würde das dann auch mal Anfangen wenn
wir mal eine WIKI Bereich gründen könnten der sich mit ZFS beschäftigt.

Gruss

joergpc
 
Lord_x schrieb:
Weiter werden schlussendlich nur "11.24m" verwendet!
Zum Vergrößern anklicken....
Nein. Die Doku ist da etwas schwammig, aber "m" sind "Million Hits". Also 11.24 Millionen Anfragen auf den Cache, davon 5.73 Millionen Treffer und 5.51 Millionen Misses. 5.52 Millionen "Feeds", also Aktualisierungen, kommen noch oben drauf.

Die Cache-Effizienz ist halt sehr von dem Zugriffsmuster abhängig. Mein Mailserver ist z.B. ein Cache-Versager:
Code: 
L2 ARC Summary: (HEALTHY)
	Passed Headroom:			133.34m
	Tried Lock Failures:			3.74m
	IO In Progress:				933
	Low Memory Aborts:			552
	Free on Write:				386.94k
	Writes While Full:			309.80k
	R/W Clashes:				274
	Bad Checksums:				0
	IO Errors:				0
	SPA Mismatch:				0

L2 ARC Size: (Adaptive)				21.63	GiB
	Header Size:			0.21%	46.22	MiB

L2 ARC Evicts:
	Lock Retries:				1.20k
	Upon Reading:				0

L2 ARC Breakdown:				46.87m
	Hit Ratio:			2.55%	1.20m
	Miss Ratio:			97.45%	45.67m
	Feeds:					3.37m

L2 ARC Buffer:
	Bytes Scanned:				2.14	PiB
	Buffer Iterations:			3.37m
	List Iterations:			212.06m
	NULL List Iterations:			35.05m

L2 ARC Writes:
	Writes Sent:			100.00%	450.00k

Der Fileserver läuft aber mittelprächtig gut:
Code: 
L2 ARC Summary: (HEALTHY)
	Passed Headroom:			313.27m
	Tried Lock Failures:			67.69m
	IO In Progress:				50.50k
	Low Memory Aborts:			559
	Free on Write:				26.87k
	Writes While Full:			177.53k
	R/W Clashes:				10.14k
	Bad Checksums:				0
	IO Errors:				0
	SPA Mismatch:				0

L2 ARC Size: (Adaptive)				95.76	GiB
	Header Size:			0.35%	346.80	MiB

L2 ARC Evicts:
	Lock Retries:				800
	Upon Reading:				14

L2 ARC Breakdown:				144.80m
	Hit Ratio:			66.87%	96.83m
	Miss Ratio:			33.13%	47.97m
	Feeds:					6.39m

L2 ARC Buffer:
	Bytes Scanned:				5.17	PiB
	Buffer Iterations:			6.39m
	List Iterations:			406.47m
	NULL List Iterations:			11.11m

L2 ARC Writes:
	Writes Sent:			100.00%	591.87k

Die oben genannten >90% Cache-Hits kommen irgendwo aus der Sun-Doku. Sind auch durchaus erreichbar, wenn der Workload stimmt.
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben