64GB RAM- aber 55GB wired: Sollte ich ARC-Größe begrenzen?

testit

Well-Known Member
Hallo,

ich habe mir kürzlich einen 64GB-Rechner angemietet und frage mich, warum 55 GB als "wired" angezeigt werden, obwohl aktuell nur ca. 5,8 GB von Prozessen etc. belegt werden. Nachstehende Infos lassen mich vermuten, dass ein Großteil der 64 GB für den ZFS ARC genutzt werden.

Ich frage mich nun, ob ich die ARC-Größe nicht von vorneherein ein wenig begrenzen sollte, weil ich noch zwei VMs laufen lassen will.
Oder spielt das keine Rolle, weil ARC, wenn ich das richtig verstanden habe, ohnehin dynamisch arbeitet und den Speicherbedarf der zwei VMs ohnehin Vorrang gibt. Kann mir von Euch jd. etwas dazu sagen?

Hier wird zwar einiges an Hintergrundinfos vermittelt, aber leider keine in der Praxis bewährten Voreinstellungen.
Da ich zwei 4TB als Mirror laufen habe: Wäre es sinnvoll, die max. ARC-Size auf 5GB zu begrenzen?

Herzlichen Dank und viele Grüße
Testit


Mem: 253M Active, 1764M Inact, 173M Laundry, 55G Wired, 5334M Free
ARC: 49G Total, 3964M MFU, 44G MRU, 209M Header, 1371M Other 46G Compressed, 48G Uncompressed, 1.05:1 Ratio

Prozesse mit Speichernutzung in MB
Summe: 5873,22 MB

1540,00
305,76
303,50
303,25
302,01
301,94
301,57
301,38
301,38
297,82
297,63
292,07
135,50
135,50
135,50
56,50
55,13
41,77
41,41
35,38
33,68
21,35
20,52
20,46
18,69
18,56
18,09
18,09
18,09
18,09
18,09
13,30
12,73
12,66
12,61
12,58
12,58
12,58
12,58
12,58
12,58
12,58
12,58
12,57
5873,22

zfs-stats -a

Code:
System Memory:

        0.38%   243.02  MiB Active,     2.78%   1.72    GiB Inact
        87.94%  54.60   GiB Wired,      0.00%   0       Bytes Cache
        8.40%   5.22    GiB Free,       0.50%   314.78  MiB Gap

        Real Installed:                         64.00   GiB
        Real Available:                 99.60%  63.74   GiB
        Real Managed:                   97.41%  62.09   GiB

        Logical Total:                          64.00   GiB
        Logical Used:                   89.15%  57.06   GiB
        Logical Free:                   10.85%  6.94    GiB

Kernel Memory:                                  1.04    GiB
        Data:                           96.46%  1.01    GiB
        Text:                           3.54%   37.84   MiB

Kernel Memory Map:                              62.09   GiB
        Size:                           87.73%  54.47   GiB
        Free:                           12.27%  7.62    GiB
 
Eigentlich wird der ARC Cache dynamisch freigegeben wenn benötigt. Da hats früher immer etwas gehackt dass das nicht schnell genug ging für manche Anwendungsfälle, seit OpenZFS (Freebsd 13) sollte das aber behoben sein. Wenn du also keine Probleme mit dem RAM hast würde ich mir erstmal keine Gedanken machen.

Wenn du den ARC begrenzen willst nicht auf sowas kleines wie 5GB, da schneidest du dir selbst in die Performance, sondern eher auf 50% des RAMS oder 2/3.
 
Hallo,

danke Dir für Deinen Beitrag!

Unter o. a. Quelle ist zu lesen:

Eine Faustregel besagt, dass 1 GB RAM für jedes 1 TB Storage vorgesehen werden sollte. Wenn Deduplizierung zum Einsatz kommt, besagt die Regel, dass 5 GB RAM pro TB an Speicher, der dedupliziert werden soll, bereitgestellt sein muss.

Daher kam ich auf die o. a. 5 GB.

Viele Grüße
testit
 
Ich denke das ist eher eine minimum Angebe.

Wie gesagt ich würde dir raten es einfach mal laufen zu lassen. Ein ServerOS wie FreeBSD ist standardmäßig sinnig konfiguriert das es für einen Großteil der Anwendungen passt.
Wenn du wirklich auf Probleme stößt kannst du immer noch eingreifen, wobei ich dann erstmal 50% vom RAM verwenden würde.
 
Das "wired" bezeichnet Speicher, welcher "vom Kernel in gebrauch" ist und nicht ausgelagert werden kann.
Ich denke das wird bei FreeBSD für den ZFS ARC cache so gelöst worden sein, da dieser ja sinnvollerweise im Speicher stehen bleiben soll. Daher "wired".
Nur meine Vermutung - aber vllt gibts hier im Forum Kollegen, welche tiefer im OS/ZFS Code drin sind, und da genaueres zu sagen können.

Wenn Deduplizierung zum Einsatz kommt...
Daher kam ich auf die o. a. 5 GB.

Nutzt du denn dedup - bzw hast es am pool aktiviert?
Wenn nein, dann kannst getrost mit 1GB RAM pro TByte rechnen;

ARC zeigt 49G - was für einen 64G Server m.E eh noch gut (wenig) ist - ich hab für ARC noch die Faustregel "nimmt sich alles an RAM minus 1 GB" im Hinterkopf - weiss allerdings jetzt nicht, ob das für 13 noch so gilt.
Der ARC wird reduziert, wenn das OS mehr Speicher anderweitig benötigt, das funktioniert out of the box.

Ich kann aus eigener Erfahrung sagen, dass 20 TBytes mit 8 GB RAM laufen - ohne erkennbare Cache Probleme; und auf der Maschine liefen auch noch ein paar Jails und ein Linux mittels bhyve.
Habe den ARC auch nie manuell eingestellt, sondern immer das OS machen lassen, von daher denke ich dass du damit (und den 64GB RAM) erstmal gut starten kannst.
Hängt aber vom RAM-Bedarf deiner VMs ab - ich könnte mir vorstellen, dass es schwierig werden könnte, wenn jede deiner VMs sagen wir mal 32 GB RAM brauchen (also nicht nur anfordern, sondern auch wirklich belegen) würde. Bei 8 oder 16 (sogar 24) GB RAM pro VM würd ich mir erstmal keine Sorgen machen.
 
Ab 13 ist das Belegen und wieder Freigeben von ARC fixer geworden, da wurde viel geschraubt. Normalerweise ist jetzt die Daumenregel, dass es eher kontraproduktiv ist, selber zu begrenzen.
Wenn du deine VMs nicht dauernd stoppst und startest, sondern durchlaufen lässt (also durchweg den RAM belegt lassen) und jeder VM z.B. 24G zugewiesen wurde, dann sollte es da keine Probleme geben. Da muss man auch mal zur Gesamtbewertung schauen, ob eine VM nicht auch 'lockerer' mit 4G auskommen kann, denn man sollte eher den RAM der VMs beschneiden, als den ARC vom Host.

Eine Faustregel besagt, dass 1 GB RAM für jedes 1 TB Storage vorgesehen werden sollte. Wenn Deduplizierung zum Einsatz kommt, besagt die Regel, dass 5 GB RAM pro TB an Speicher, der dedupliziert werden soll, bereitgestellt sein muss.
Sollte vs. muss. Ersteres betrifft die Performance, je mehr ARC, desto mehr Performance.
Wer wirklich Deduplizierung braucht/haben will, der sollte die Maschine dafür exklusiv nutzen.
 
Eigentlich wurde es schon gesagt: Zwischen FreeBSD 12.x mit dem alten ZFS on FreeBSD und FreeBSD 13.0 mit OpenZFS hat sich die ARC-Implementierung grundlegend verändert. In FreeBSD 12.x war es generell eine gute Idee den ARC zu begrenzen, einfach weil er zu träge freigegeben wurde. Ich habe für alles, was nicht exklusiv Fileserver gespielt hat, stumpf auf 8 Gigabyte begrenzt und bin immer gut damit gefahren. In FreeBSD 13.0 ist es meiner Erfahrung nach in allen Situationen kontraproduktiv den ARC zu begrenzen. Eine Begrenzung führt nur zu vermeidbaren I/O-Latenzen, im Extremfall sogar zu sekundenlangem I/O-Aussetzern.

Zu den VMs sollte man noch wissen, dass man auf dem Dataset mit den Images oder den ZFS Volumes primarycache=metadata setzen sollte oder vielleicht sogar muss. Denn ansonsten wird doppelt gecached. Einmal durch ZFS auf dem Host und einmal im Gast. Das verschwendet RAM ohne Ende. :)
 
Das "wired" bezeichnet Speicher, welcher "vom Kernel in gebrauch" ist und nicht ausgelagert werden kann.
Ich denke das wird bei FreeBSD für den ZFS ARC cache so gelöst worden sein, da dieser ja sinnvollerweise im Speicher stehen bleiben soll. Daher "wired".
Nur meine Vermutung - aber vllt gibts hier im Forum Kollegen, welche tiefer im OS/ZFS Code drin sind, und da genaueres zu sagen können.
Hallo,

dass das so ist, wird ja unter dem von mir verlinkten Beitrag bestätigt.

Viele Grüße
testit
 
Ab 13 ist das Belegen und wieder Freigeben von ARC fixer geworden, da wurde viel geschraubt. Normalerweise ist jetzt die Daumenregel, dass es eher kontraproduktiv ist, selber zu begrenzen.
Wenn du deine VMs nicht dauernd stoppst und startest, sondern durchlaufen lässt (also durchweg den RAM belegt lassen) und jeder VM z.B. 24G zugewiesen wurde, dann sollte es da keine Probleme geben.

Vor dem Wechsel auf eine neue Maschine mit 64GB RAM hatte ich eine mit nur 8GB RAM und hatte daher die zwei VMs auf 1GB RAM pro VM begrenzt. Die liefen auch auf der alten Maschine mit nur 1GB RAM wie am Schnürchen, wobei ich diese VMs in erster Linie dazu nutze, neue Applikationen auszuprobieren, wie etwa aktuell Postfix, Roundcube, Nextcloud, spamd.

Da muss man auch mal zur Gesamtbewertung schauen, ob eine VM nicht auch 'lockerer' mit 4G auskommen kann, denn man sollte eher den RAM der VMs beschneiden, als den ARC vom Host.
vgl. oben

Sollte vs. muss. Ersteres betrifft die Performance, je mehr ARC, desto mehr Performance.
Wer wirklich Deduplizierung braucht/haben will, der sollte die Maschine dafür exklusiv nutzen.
Auf der Maschine ist dedup deaktviert!

Danke für die Infos!

Viele Grüße
testit
 
Eigentlich wurde es schon gesagt: Zwischen FreeBSD 12.x mit dem alten ZFS on FreeBSD und FreeBSD 13.0 mit OpenZFS hat sich die ARC-Implementierung grundlegend verändert. In FreeBSD 12.x war es generell eine gute Idee den ARC zu begrenzen, einfach weil er zu träge freigegeben wurde. Ich habe für alles, was nicht exklusiv Fileserver gespielt hat, stumpf auf 8 Gigabyte begrenzt und bin immer gut damit gefahren. In FreeBSD 13.0 ist es meiner Erfahrung nach in allen Situationen kontraproduktiv den ARC zu begrenzen. Eine Begrenzung führt nur zu vermeidbaren I/O-Latenzen, im Extremfall sogar zu sekundenlangem I/O-Aussetzern.

Zu den VMs sollte man noch wissen, dass man auf dem Dataset mit den Images oder den ZFS Volumes primarycache=metadata setzen sollte oder vielleicht sogar muss. Denn ansonsten wird doppelt gecached. Einmal durch ZFS auf dem Host und einmal im Gast. Das verschwendet RAM ohne Ende. :)

Vielen Dank für die sehr interessanten Infos!

Den Aspekt mit "primary cache" und ZFS i. V. mit VMs kannte ich noch nicht.

EDIT

@Yamagi Ich würde Deinen Hinweis gerne nochmal aufgreifen.

Hier ist auch nochmal eine ganz gute Zusammenfassung Pro/Contra zu HOST-Caching vs. Guest-Caching (VirtualBox).
Bspw. wäre alternativ auch möglich, den HOST-IO-Cache des Virtual Storage Controlers mittels "--hostiocache off" zu deaktivieren und dadurch "primarycache=metadata" zu umgehen.

Die VirtualBOX-VMs liegen standardmäßig in /root/VirtualBox VMs.
Ich frage mich nun, wie der Befehl zfs set primarycache=metadata ... für mein System eigentlich aussehen müsste, um ein Cachen der VM-Dateien in /root/VirtualBox VMs zu verhindern?

Wo hängt denn (vgl. unten) /root nun drin?
Entspricht das zroot/ROOT?

Viele Grüße
testit

zpool status

zpool: zroot
state: ONLINE
config:

NAME STATE READ WRITE CKSUM
zroot ONLINE 0 0 0
mirror-0 ONLINE 0 0 0
ada0p3 ONLINE 0 0 0
ada1p3 ONLINE 0 0 0

errors: No known data errors

# zfs list -r pool zroot
cannot open 'pool': dataset does not exist
NAME USED AVAIL REFER MOUNTPOINT
zroot 187G 3.33T 96K /zroot
zroot/ROOT 183G 3.33T 96K none
zroot/ROOT/default 183G 3.33T 183G /etc
zroot/tmp 1.02M 3.33T 1.02M /tmp
zroot/usr 2.17G 3.33T 96K /usr
zroot/usr/home 32.2M 3.33T 32.2M /usr/home
zroot/usr/ports 1.45G 3.33T 1.45G /usr/ports
zroot/usr/src 702M 3.33T 702M /usr/src
zroot/var 1.10G 3.33T 96K /var
zroot/var/audit 96K 3.33T 96K /var/audit
zroot/var/crash 96K 3.33T 96K /var/crash
zroot/var/log 14.5M 3.33T 14.5M /var/log
zroot/var/mail 1.09G 3.33T 1.09G /var/mail
zroot/var/tmp 96K 3.33T 96K /var/tmp
 
Zuletzt bearbeitet:
Bspw. wäre alternativ auch möglich, den HOST-IO-Cache des Virtual Storage Controlers mittels "--hostiocache off" zu deaktivieren und dadurch "primarycache=metadata" zu umgehen.
Wenn man es 100% korrekt machen will, müsste man sowieso noch mal den jeweiligen Gast mit einem Dateisystembenchmark ausmessen und dann anhand des Gesamtspeicherverbrauchs in Gast und Host entscheiden, was für das Einsatzszenario optimal ist. Denn verschiedene Gäste verhalten sich in Sachen Dateisystemcache schon sehr unterschiedlich. Beispielsweise cached Linux extrem aggressiv, bis der ganze RAM voll ist, während Windows sich sehr beschränkt.

Wo hängt denn (vgl. unten) /root nun drin?
Entspricht das zroot/ROOT?
Du nutzt Boot Environments. Damit liegt /root/ auf dem gerade aktiven Environment. Da du nur eines hast, ist es zroot/ROOT/default. Wenn du darauf den Cache abschaltest, schaltest du ihn allerdings für einen größeren Teil des System ab, was vielleicht nicht optimal ist. Ich würde daher ein eigenes Dataset für die Images angelegen und sie darauf kopieren. Was allerdings, je nach Größe der Images, schon einige Zeit dauern kann.
 
Zurück
Oben