FreeNAS und RAM Wired (memory leak?)

[roki100]

Hallo Allerseits,

soweit ich verstanden habe, verbraucht FreeNAS ca. 80% vom gesamten (RAM) Speicher.

Mein System:
FreeNAS 11.1 U5
8 GB Ram
2x 1TB gespiegelt

Im iocage (jail) läuft ein Apache-Server mit MariaDB. Hierfür würde ich gerne mehr RAM (4GB) zur Verfügung stellen.

Wie reduziere ich den Speicherverbrauch im FreeNAS? Bei einem System wie meinem, reichen doch eigentlich 3-4GB und der Rest (dachte ich mir) bleibt dann für iocage übrig. Geht das?

Wie man im top sieht, reicht der 8GB Speicher nicht aus (es wird geswapt :( ):

Code:

73 processes:  1 running, 72 sleeping
CPU:  1.7% user,  0.0% nice,  2.2% system,  0.2% interrupt, 95.9% idle
Mem: 251M Active, 304M Inact, 1039M Laundry, 6082M Wired, 261M Free
ARC: 4714M Total, 1221M MFU, 2879M MRU, 16M Anon, 45M Header, 552M Other
	3555M Compressed, 5403M Uncompressed, 1.52:1 Ratio
Swap: 4096M Total, 118M Used, 3978M Free, 2% Inuse
...

 

[MrToddsFriends]

Wie man im top sieht, reicht der 8GB Speicher nicht aus (es wird geswapt :( ):

Grundsätzlich nicht anders zu erwarten. Die Anmerkung "A minimum of 8 GB of RAM is required" in der FreeNAS Doku gilt für einen einfachen Fileserver ohne Jails, Plugins und VMs.
http://doc.freenas.org/11/intro.html#ram

"Wired" ist einschließlich des ARC (ZFS Read Cache).
http://doc.freenas.org/11/zfsprimer.html

 

[MrToddsFriends]

Noch eine Antwort hinterher geschoben: Neulich habe ich eine kleine Zusammenfassung gepostet, wie das Swap-Verhalten von FreeNAS im Zaum gehalten werden kann, weil seit Version 9.10 vermehrt Swapping auftritt.
https://forums.freenas.org/index.php?threads/memory-and-swap-usage.64536/#post-462625

Ändert aber nichts der Aussage in meiner ersten Antwort. 8GB RAM sind zu wenig, um einen substantiellen Anteil davon für einen Jail abzuzwacken. Swap-Nutzung ist da noch ein kleines Problem. Du wärst nicht der erste, dessen FreeNAS-Maschine irgendwann komplett unbedienbar ist oder der sogar einen Datenverlust erleidet.

 

[roki100]

Danke für die Antwort.

Du wärst nicht der erste, dessen FreeNAS-Maschine irgendwann komplett unbedienbar ist oder der sogar einen Datenverlust erleidet.

Das macht mir jetzt etwas sorgen :(

Die Anmerkung "A minimum of 8 GB of RAM is required" in der FreeNAS Doku gilt für einen einfachen Fileserver

8GB RAM für 2 SMB User und 1 AFP User? :( Das komische, es lief vorher mit FreeNAS 9 problemlos (wared + php5, mysql5...).

Ich habe die Option "autotune" aktiviert. Mal sehen ob das was bringt. Leider kann mein Mainbaord nicht mehr als 8GB verwalten.

 

[roki100]

Autotune scheint doch was zu bewirken. Der Speicherverbrauch bleibt konstant unter 5GB! Nun lese ich in anderen Beiträgen, dass Autotune Probleme bereiten kann....? Und in der Doku steht, dass die Option Autotune als vorübergehende Lösung aktiviert werden kann/soll, bis mehr RAM nachgerüstet wird. :(

 

[MrToddsFriends]

Autotune scheint doch was zu bewirken. Der Speicherverbrauch bleibt konstant unter 5GB! Nun lese ich in anderen Beiträgen, dass Autotune Probleme bereiten kann....? Und in der Doku steht, dass die Option Autotune als vorübergehende Lösung aktiviert werden kann/soll, bis mehr RAM nachgerüstet wird. :(

Interessehalber: Welche Tunables werden durch das Verwenden von Autotune auf Deinem System gesetzt?
http://doc.freenas.org/11/system.html#tunables

Aus der Erinnerung heraus kenne ich vor Allem Postings, bei denen Autotune auf Verdacht auf Systemen mit relativ viel RAM (> 64 GB) verwendet wurde und dort Probleme bereitete.

 

[roki100]

Interessehalber: Welche Tunables werden durch das Verwenden von Autotune auf Deinem System gesetzt?

Hier ein Screenshot von einem anderen System, mit der selben Hardware, jedoch mit 2x500GB Festplatte.



Mehrere Stunden sind vorbei und kein Swapping mehr.

 

[roki100]

Ein anderes Mainboard mit 16GB Ram eingebaut, autotune deaktiviert und der Ram läuft voll. Swapping Problem besteht also weiterhin. Liegt es vll. an Replication?

Code:

CPU:  0.6% user,  0.0% nice,  0.5% system,  0.0% interrupt, 98.9% idle
Mem: 36M Active, 174M Inact, 1277M Laundry, 14G Wired, 265M Free
ARC: 12G Total, 10G MFU, 1225M MRU, 2774K Anon, 61M Header, 579M Other
	10G Compressed, 12G Uncompressed, 1.23:1 Ratio
Swap: 2048M Total, 11M Used, 2037M Free

 

[MrToddsFriends]

Ein anderes Mainboard mit 16GB Ram eingebaut, autotune deaktiviert und der Ram läuft voll. Swapping Problem besteht also weiterhin. Liegt es vll. an Replication?

"Läuft voll": Es ist völlig normal, dass große Teile vom verfügbaren RAM für den ARC verwendet werden und damit in den Physical Memory Stats von top in Wired vermerkt werden.

"Swapping Problem besteht also weiterhin": Der oben gegebene Hinweis auf diese kleine Zusammenfassung
https://forums.freenas.org/index.php?threads/memory-and-swap-usage.64536/#post-462625
ist auch mit mehr als 8GB RAM aktuell.

Ein Versuch mit den beiden Tunables vm.v_free_target und vfs.zfs.arc_free_target sollte allerdings schnell zum Ziel führen. Bei meiner Konfiguration ohne diese beiden Tunables waren es Scrubs, die regelmäßig zu einer Swap Usage > 0 geführt haben, das kann bei anderen Konstellationen wohl auch anders sein.

 

[roki100]

ich habe die Tunables jetzt so gesetzt:
sysctl vm.v_free_target gibt aus:

Code:

vm.v_free_target: 65536

und sysctl vfs.zfs.arc_free_target:

Code:

vfs.zfs.arc_free_target: 65535

System Neugestartet und dann per scp ca. 13GB Daten auf dem anderen FreeNAS Server übertragen. Ergebnis: 12+GB RAM für ARC(?) Wenn man (iocage) FAMP betreibt, nicht gerade optimal.
sysctl vfs.zfs.arc_max

Code:

vfs.zfs.arc_max: 15510441984

sysctl vfs.zfs.arc_min

Code:

vfs.zfs.arc_min: 1938805248

also ca. 2gb min. und 15.5gb max. nur für ARC? Wenn Replication (manuell und nicht self.autom.) gestartet wird, dann wird nach paar Tagen oder Wochen die max. grenze schnell erreicht und wie in meinem Fall geht es sogar über die max. grenze und es wird geswappt.


EDIT:
ich habe jetzt folgendes (auf 8GB FreeNAS Server) gemacht:

Code:

sysctl hw.physmem | cut -d ' ' -f 2

gibt aus:
8549564416

Code:

expr 8549564416 / 2

Ergebnis: 4274782208
Tunable für vfs.zfs.arc_max mit dem Wert 4274782208 gesetzt (Typ: sysctl), FreeNAS Neugestartet... und dann mit scp hin und her Daten kopiert und siehe da, kein Swapping mehr.

 

[MrToddsFriends]

Stimmt schon, das Setzen von vm.v_free_target und vfs.zfs.arc_free_target auf den Wert 65536 scheint einen etwas verschwenderischen Umgang mit RAM nach sich zu ziehen. Stattdessen den Wert 32768 zu verwenden, lindert diese Verschwendung nach Berichten andere User. Eventuell findet man mit etwas Experimentieren noch sparsamere Werte.

Gegenüber dem Setzen von vfs.zfs.arc_max hat obige Methode den Vorteil, dass günstige Werte, die Swapping zuverlässig verhindern und für eine gute Ausnutzung des RAM durch ARC sorgen, nicht von weiteren Umständen wie der Menge an installiertem RAM oder dem Speicherbedarf von VMs/Plugins/Jails abhängig sind.

Eventuell führt Setzen von vfs.zfs.arc_max ohne viel Experimentieren schneller zum Ziel, sofern sich diese weiteren Umstände nicht ändern.

 

[roki100]

Auf jeden Fall ist halbieren des Speichers für ARC nötig, wenn Speicher für andere Dienste (wie in meinem Fall iocage/FAMP) benötigt werden. In der FreeBSD Doku ist folgendes zu lesen:

• vfs.zfs.arc_max - Maximale Größe des ARC. Die Voreinstellung ist der gesamte RAM weniger 1 GB oder die Hälfte vom RAM, je nachdem, was mehr ist. Allerdings sollte ein niedriger Wert verwendet werden, wenn das System weitere Dienste oder Prozesse laufen lässt, welche Hauptspeicher benötigen...

Zu beachten ist außerdem das:

19.6.2.1. Hauptspeicher

• Als absolutes Minimum sollte der gesamte verfügbare Hauptspeicher mindestens ein Gigabyte betragen. Die vorgeschlagene Menge an RAM ist bedingt durch die Poolgröße und welche Eigenschaften von ZFS verwendet werden. 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. Obwohl manche Anwender ZFS mit weniger RAM einsetzen, stürzen Systeme häufiger wegen unzureichendem Hauptspeicher ab. Weitere Anpassungen sind unter Umständen nötig für Systeme mit weniger als die vorgeschlagene Menge an RAM.

https://www.freebsd.org/doc/de/books/handbook/zfs-advanced.html

 

[MrToddsFriends]

Zu beachten ist außerdem das:

19.6.2.1. Hauptspeicher

• Als absolutes Minimum sollte der gesamte verfügbare Hauptspeicher mindestens ein Gigabyte betragen. Die vorgeschlagene Menge an RAM ist bedingt durch die Poolgröße und welche Eigenschaften von ZFS verwendet werden. 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. Obwohl manche Anwender ZFS mit weniger RAM einsetzen, stürzen Systeme häufiger wegen unzureichendem Hauptspeicher ab. Weitere Anpassungen sind unter Umständen nötig für Systeme mit weniger als die vorgeschlagene Menge an RAM.

https://www.freebsd.org/doc/de/books/handbook/zfs-advanced.html

Die 8 GB als Minimum, die im FreeNAS Handbuch genannt werden sind nicht aus den Fingern gesogen. Diese Angabe geht darauf zurück, dass in der Vergangenheit Fälle von Datenverlust bei Vorhandensein von weniger als 8GB RAM auftraten.

Die "1 GB RAM pro 1 TB Storage" Regel ist zwar im FreeNAS Handbuch ebenfalls erwähnt, es wurde hier im Forum allerdings bereits sehr oft durchgekaut, das dies bestenfalls eine sehr grobe und möglicherweise veraltete Faustregel sei.

 

[roki100]

In den paar Monate seit ich FreeNAS einsetze, habe ich echt viel darüber gelesen. Datenverluste sind unterschiedlich und in den meisten Fällen ist die Ursache 1. unbekannt oder 2. defekte Hauptspeicher. Das kann aber auch mit 64GB RAM ECC auftreten. ZFS reagiert auf Hauptspeicher Fehler viel empfindlicher als andere Dateisysteme, daher wird ECC empfohlen. Ich empfehle aber einen ordentlichen Hardware Check vor dem FreeNAS Einsatz, egal ob dabei ECC oder non-ECC RAM eingesetzt werden.
Vorher ein Hardware Check ist also m.M. ein muss.

Wer auf Speicherfressende Deduplication von FreeNAS verzichten möchte und trotzdem doppelte Dateien verhindern möchte, dafür gibt es genügend Scripts.

 

[MrToddsFriends]

In den paar Monate seit ich FreeNAS einsetze, habe ich echt viel darüber gelesen. Datenverluste sind unterschiedlich und in den meisten Fällen ist die Ursache 1. unbekannt oder 2. defekte Hauptspeicher.

Ich habe versucht darauf hinzuweisen, dass das im Handbuch angegebene Hauptspeicher-Minimum für FreeNAS vor geraumer Zeit (tatsächlich war es bereits 2013) auf 8 GB angehoben wurde, weil Nutzer ernsthafte Probleme hatten und soweit ich mich erinnern kann waren auch Fälle von Datenverlust darunter. Dies wäre meiner Einschätzung nach nicht passiert, wenn es sich lediglich um Fälle mit defekter Hardware gehandelt hätte.

In der Folge wurde dann zunächst eine Warnung und dann eine Fehlermeldung in den FreeNAS Installer eingebaut, um Installationsversuche auf Systemen mit weniger als 8 GB RAM zu verhindern. Natürlich nennt auch der Hardware Recommendations Guide ein Minimum von 8 GB.

Genauso alt wie das Anheben des Minimums auf 8 GB sind die Diskussionen darum. Freilich gibt es User, die ein funktionierendes System mit weniger als 8 GB am Laufen haben. Der Tenor hier im Forum ist: So etwas mag durchaus so lange funktionieren bis es irgendwann doch schief geht (bestimmt gerade dann, wenn man es am Wenigsten brauchen kann).

Von Deduplizierung war hier von meiner Seite gar nicht die Rede, das machen wegen sehr hohem Speicherbedarfs wohl auch nur wenige User.

Von daher: Viel Erfolg mit Deinem FreeNAS System.

 

[roki100]

Ich Danke Dir für die Informationen. Darüber wurde viel diskutiert und ich hoffe ich nerve nicht mit jetzige Diskussion. Vielleicht hilft es dem einen oder anderen User dennoch.

Es gilt: wer Jails/OwnCloud oder NextCloud oder andere WebProgramme einsetzt und dabei merkt, das wenig Hauptspeicher für die Dienste im Jail zur verfügung steht, dann bringt es nicht wirklich viel auf einem FreeNAS System (z.B.) mit 1TB Festplatte und 16GB RAM... auf 32GB RAM aufzurüsten, weil ARC sich das meiste so oder so wegnimmt und ca. 1gb -/+ für andere (Jail) Dienste übrig lässt. Die Lösung ist oben bereits erwähnt: Tunnables für vfs.zfs.arc_max setzen.

Mehr Hauptspeicher lohnt sich m.M. nur dann, wenn auch mehr TB / größere Festplatten zum Einsatz kommen.

Es hat sich bei ZFS (laut meiner Recherche) über die Jahren wenig verändert. Zumindest nicht in die Richtung, mehr Hauptspeicher zu verbrauchen. Viel mehr waren es andere Dienste die dazu führten (wie z.B. Samba in der Version 11.1 U4 was sich aber als Speicherleck herausstellte).

Von Deduplizierung war hier von meiner Seite gar nicht die Rede, das machen wegen sehr hohem Speicherbedarfs wohl auch nur wenige User.

Es ist in der FreeNAS Doku nicht so erwähnt, dass die aktivierte Deduplizierung Funktion mehr Hauptspeicher verbraucht. Es war meinerseits nur als ein Hinweis erwähnt, das zu beachten. Denn gerade dann, gelten die verbreitete Regel 1GB RAM pro 1TB HDD/SDD nicht mehr.

Man beachte einige Diskussionen im FreeBSD Foren , wie z.B. FreeBSD + ZFS und Desktops - Diskussionen, dies kann man mit FreeNAS ZFS und Jails vergleichen und seinen System optimieren.