Jump to content

Wie manuell das RAM-Cache leeren anstossen?


Recommended Posts

Hallo Allerseits.

 

Ich habe nun diverse eher erfolglose Suchen hier nach Cache flush, Ram leeren durchgeführt und auch die FAQ in den DOCs danach abgesucht.

Alles war ich fand waren Infos zum Mover und Dateien im Pool-Cache. Mir geht es aber im den RAM, der zwischenzeitlich als Cache fungiert.

 

unraid (linux) nutzt ja RAM als Schreibcache (die Größe ist ja einstellbar).

Wie kann ich unraid im laufenden Betrieb dazu bringen diesen RAMCache zu leeren und den darin gelagerten Bereich auf die Datenträger zu schreiben?

 

Link to comment

Das geht m.W.n nur indirekt über die Einstellungen vm.dirty_background_ratio und vm.dirty_ratio.

Damit sagt man dem Kernel (der RAM Cache gehört gar nicht zu UNRAID), wieviel Speicher er maximal benutzen soll und ab wann er anfängt, den Cache rauszuschreiben und zu leeren.

Die etwas komplexen Zusammenhänge erläutert https://lonesysadmin.net/2013/12/22/better-linux-disk-caching-performance-vm-dirty_ratio/

(hoffentlich)

Es gibt dabei keine wirklich "gute" Kombination, Du mußt etwas rumprobieren, um eine zu finden, die auf Deiner Hardware "glatt" funktioniert (also eine Balance zwischen "sammeln" und "blockierendem Schreiben" findet, so dass keine hässliichen Pausen entstehen).

Es ist natürlich immer einfacher, wenn die physikalischen Platten eine hohe Schreibrate haben (also eine NVMe ist immer eine gute Idee als Cachlaufwerk, ein GUTE Nvme ist eine bessere Idee :-))) )

Gerade bei NVMes ist viel Schrott auf dem Markt, viele können einen hohe Schreibrate nicht lange durchhalten, die sind ungeeignet für den Job, weil der Kernel sich an die Rate anpasst, aber nicht darauf vorbereitet ist, dass sie abrupt abbricht. Deshalb kommt es oft zu Stockungen wenn der an sich tolle RAM Cache entleert werden soll und man erreicht das Gegenteil von der gewünschten Leistung.

Deshalb die Cachplatten mal durchtesten, ob sie auch Dateien mit 100Gb oder mehr in einem Stück schnell schreiben können. Dann vergisst Du ganz schnell, dass da noch ein RAM Cache ist, Du bemerkst ihn gar nicht mehr.

 

Link to comment
5 hours ago, DataCollector said:

Wie kann ich unraid im laufenden Betrieb dazu bringen diesen RAMCache zu leeren und den darin gelagerten Bereich auf die Datenträger zu schreiben?

Das passiert automatisch nach 30 Sekunden bzw nachdem wie vm.dirty_expire_centisecs eingestellt ist (Standard ist 3000 Hundertstelsekunden). Der Wert kann wie folgt ausgelesen werden:

sysctl -a | grep dirty

 

Man kann diesen Wert zb so verkürzen:

echo 2000 > /proc/sys/vm/dirty_writeback_centisecs

 

Ich kann davon aber nur abraten, denn es gibt in Programmen Abläufe wo temporäre Dateien erstellt und später wieder gelöscht werden. Durch den RAM Cache verhindert man, dass diese jemals auf dem Datenträger landen, was ja gut ist. Komplett deaktivieren wird das System spürbar verlangsamen.

 

Ist dagegen ein Betrieb ohne USV geplant, würde ich den Wert auf 1 Sekunde reduzieren. Je nachdem wie wichtig die Daten sind.

 

Willst du dagegen zb wegen einem Benchmark kurz den RAM Cache leeren, musst du nur das ausführen:

sync; echo 1 > /proc/sys/vm/drop_caches

 

Mit dem folgenden Befehl kannst du übrigens die inodes und dentries auch aus dem Cache werfen, was aber erst recht unsinnig ist, weil dadurch alle HDDs hochfahren müssen damit ihre Verzeichnisstruktur wieder bekannt wird:

sync; echo 2 > /proc/sys/vm/drop_caches

 

  • Thanks 1
Link to comment
16 hours ago, Michael Meiszl said:

Das geht m.W.n nur indirekt über die Einstellungen vm.dirty_background_ratio und vm.dirty_ratio.

Damit sagt man dem Kernel (der RAM Cache gehört gar nicht zu UNRAID), wieviel Speicher er maximal benutzen soll und ab wann er anfängt, den Cache rauszuschreiben und zu leeren.

Bevor es mißverstanden wird.

Mir geht es darum in einem Moment manuell einen befehl abzusetzen, der unraid veranlasst ab dem moment die flüchtigen CacheDaten aus dem ram dahin zu schreiben, wo sie sicherer sind um den RamCache für andere Daten frei zu bekommen. Vielleicht sogar als script.

Ich will (aktuell) nicht das gesamte Cacheverhalten von unraid ändern.

 

Ich will also wirklich nur irgendwann manuell einen Befehl "FlusghRam" oder so eingeben und dann sichert er eben die flüchtigen RamCache Daten auf deren Ziel, wo sie ja sowieso hin sollen.

Link to comment
16 hours ago, mgutt said:

Das passiert automatisch nach 30 Sekunden

Ich habe dahingehend in unraid meines Wissens nichts verändert.

 

Daß der Ram Cache nach 30 Sekunden von allein leer läuft kann ich irgendwie nicht erkennen.

00:31:30 Uhr Kopiervorgang von Krusader von externer Netzwerkfreigabe auf unraid Share pausiert.
00:32:20 Uhr Schreibrate in Main Tab auf die gerade beschrieben Festplatte ist auf 0 gedroppt.

 

00:36:00
   Anzeige Stats Memory Ram zeigt orangefarben den Cache weiterhin zu fast 100% belegt an.
   Anzeige Stats Storage zeigt abgesehen von einem kleinen Spike keine Schreiboperation an.
   Siehe Screenshot.

 

RAM-Cache.jpg

Edited by DataCollector
Link to comment
6 hours ago, DataCollector said:

Daß der Ram Cache nach 30 Sekunden von allein leer läuft kann ich irgendwie nicht erkennen.

 

 

6 hours ago, DataCollector said:

00:32:20 Uhr Schreibrate in Main Tab auf die gerade beschrieben Festplatte ist auf 0 gedroppt.

 

 

du siehst ja dass die Daten nach knapp 1 min geschrieben wurden.

 

die Daten liegen wahrscheinlich immer noch im ram cache, die werden ja nicht nach dem Schreiben aus dem RAM "gelöscht", erst wenn  die Date n nicht mehr in Nutzung sind und der RAM cache für "Neueres" genutzt werden soll.

 

https://unix.stackexchange.com/questions/87908/how-do-you-empty-the-buffers-and-cache-on-a-linux-system

 

So solltest du den cache leeren können wenn du Bedarf haben solltest ...

Link to comment

also ich würde der stats Anzeige auch nicht trauen. Der RAM Cache ist dynamisch. Wenn das OS Platz für etwas Anderes braucht, dann wird er abgeben. Ansonsten wird jede freie Page wieder dem Cache zugeschlagen.

Das heißt aber nicht, dass er auch belegt ist.

 

Ich weiß, intuitiv erwartet jeder, dass die unbenutzten Pages dem "freien" Speicher zugeordnet werden, dem ist aber nicht so. Es ist nämlich viel arbeitsintensiver, die Kerneltabellen für eine neue Page anzulegen, als den Link auf dieselbe in den Tabellen für frei/cache/belegt zu verschieben. Also arbeitet die Speicherverwaltung vorherschauend und grabbelt sich alles, was nicht schnell genug auf die Bäume kommt.

Es gibt noch andere Speicherzustände, aber die führt dieses Stats wohl nicht mit an.

 

Guck mal mit "top", da sieht es dann schon anders aus:

 

MiB Mem : 128632.8 total, 104635.4 free,  15305.2 used,   8692.3 buff/cache
MiB Swap:      0.0 total,      0.0 free,      0.0 used. 111127.4 avail Mem

 

Hier ist der Cache also nur so 8G groß und 104G sind free. Das Stats zeigt aber auch hier "alles für den Cache" an.

 

Und den von Dir gesuchten "cache flush" Befehl hat mgutt ja oben schon erwähnt: "sync"

 

Keine Panik auf der Titanic :-)))

 

Link to comment

Seine Angst besteht wohl mehr darin, dass die Daten stundenlang im RAM rumliegen und nie auf die Platte kommen, weil der Blitzeinschlag vorher ist.

Aber das ist völlig unbegründet, selbst mit den üblichen 30 Sekunden passiert das kaum, denn das sind MAXIMAL Zahlen.

Rausgeschrieben wird, sobald Linux meint, es wäre nicht ausgelastet, also eigentlich immer. Die 30 Sekunden sind die Notbremse, wenn bis dahin noch nicht geschrieben wurde, werden die auslastenden Prozesse gestoppt und erstmal Tabula RAM-a gemacht und der Cache geleert.

 

Was mich allerdings an seiner stats Grafik echt stören würde, ist die stoßweise LAN Auslastung. Und das bei nur 1Gbe Verbindung!. DA würde ich mal nachforschen und die Bremse beseitigen.

  • Like 1
Link to comment
25 minutes ago, Michael Meiszl said:

Was mich allerdings an seiner stats Grafik echt stören würde, ist die stoßweise LAN Auslastung. Und das bei nur 1Gbe Verbindung!. DA würde ich mal nachforschen und die Bremse beseitigen.

ich schätze da die parity mitläuft hat er ja "nur" 30 - 50 MB/s ... da langweiligt sich das Netzwerk ;)

Link to comment
3 hours ago, alturismo said:

du siehst ja dass die Daten nach knapp 1 min geschrieben wurden.

Soweit ich es glaube gelesen zu haben beträgt der Cache im Ram rund 20% des Ram.

Bei 128GB DDR4 Ram sind dan etwas über 20GB.

Der kurze Peak im Storage von wenigen Sekunden war nicht lang genug 20GB Ram wegzuschreiben.

Meine Festplatten schreiben in Spitze etwas über 250MByte/s weg. Der WritePeak um 20GB vom RAM auf Festplatte zu schreiben hätte also

20.000 MB : 250 MByte/s = 80Sekunden dauern müssen.

Das sehe ich da nicht.

 

Link to comment
2 hours ago, Michael Meiszl said:

Seine Angst besteht wohl mehr darin, dass die Daten stundenlang im RAM rumliegen und nie auf die Platte kommen, weil der Blitzeinschlag vorher ist.

Mein Bedarf besteht darin, daß ich aktuell viele TB weise an Daten ins Array kopiere und zwischenzeitlich umkonfiguriere.

Ich möchte das System aber bevorzugt nur umstellen, wenn gerade keien flüchtigen Cachedaten ungesichert im RAM liegen.

 

2 hours ago, Michael Meiszl said:

Was mich allerdings an seiner stats Grafik echt stören würde, ist die stoßweise LAN Auslastung.

Das ist ja, als ich den Transfer gestoppt hatte.

Das, was Du da siehst, sind nur die Aktualisierungen des WebGUI udn des krusader/ich777 Dockers.

 

2 hours ago, Michael Meiszl said:

Und das bei nur 1Gbe Verbindung!

2.5GBLan. Sie ist nur eben aktuell nicht ausgelastet.

Die Bremse ist der (zum pruefen ob der Cache geleert wird) gestoppte transfer des krusaders.

Ich schrieb ja: 00:31:30 Uhr Kopiervorgang von Krusader von externer Netzwerkfreigabe auf unraid Share pausiert.

Die Grafik beginnt erst irgendwo wenige Sekunden danach.

Ich wollte ja sehen ob der RamCache welcher durch die bis dahin stattgefundene Kopiererei von mehreren TB an Daten von LAN auf Array

wirklich nach 30 Sekunden aktivität zeigt und auf Platte kopiert wird.

Und das sehe ich eben nicht in der Anzeige.

 

Siehe auch beiligende Grafik.

Hier habe ich den Transfer (krusader Docker) auch gestoppt und um 10:43 Uhr erst Fortsetzen geklickt.

(Aktuell beschreibt unraid eien Platte irgendwo bei knapp unter 50%, weshalb hier nun die Festplatte bei ca. 160MByte/s begrenzt. Die sind eben nur im Außenbereich bei sequentiellem Schreiben großer Dateien sehr schnell [knapp über 250MByte/s].)

 

 

RAM-CAHE-NEUr.png

Link to comment
13 minutes ago, Michael Meiszl said:

es ist ja nicht klar, ob die Daten zu "richtigen" Festplatten, oder zu einem NVMe Cache Laufwerk geschrieben werden. Meins schafft da lockere 7Gb/s.

 

Ich glaube ich schrieb, daß ich von LAN auf Array mit Festplatten schreibe.

Der NVMeCache ist für das Share bei dieser Befüllung ausgeschaltet, weil ich mit 350TB Write die NVMe SSD nicht vorzeitig verschleißen will.

Meien Samsung 970 EVo Plus schaffen einzeln keien 7GByte/s. Aber sie sind ja auch aktuell nicht im Share eingerichtet.

Link to comment

Egal, Fakt ist, die Memory Grafik hat keinerlei Realitätsbezug und es gibt keinen Grund, Panik wegen eines RAM Caches zu haben.

Die Samsung sollte aber so 3GByte/s schaffen, nur natürlich nicht für 350TB, die passen da wohl kaum drauf. Insofern ist auch Deine Verschleißangst recht unbegründet. Irgendwann ist die Samsung voll und UNRAID schreibt dann eh direkt ins Array rein.

 

Aber 350TB? das ist schon heftig, da brauchst Du Dir die nächsten Wochen nix vornehmen :-)))

 

Link to comment
33 minutes ago, DataCollector said:

Siehe auch beiligende Grafik.

 

das sieht alles ok aus wie es ist

 

wenn du zig GB "ohne" echtes Schreiben "nur" in den RAM schieben würdest hättest du auch keinerlei "Bremse", sprich, bei deinem 2.5G Netzwerk würde der Vollgas schreiben ... und falls dein cache übrigens mit "aktiven" Daten belegt ist, bleibt beim kopieren wahrscheinlich gar nichts im cache ... wovon ich jetzt bei 128G Ram zwar nicht ausgehe ;) aber das nur am Rande erwähnt ...

 

mach doch einen spindown, und öffne danach die Datei von der physischen disk ... wenn jetzt ein spinup kommt ist die Datei nur noch auf der disk und nicht mehr im RAM, zum Beispiel einer Datei die du vor paar Minuten dahin geschoben hast ...

 

das passt schon alles ;)

Link to comment
49 minutes ago, Michael Meiszl said:

Die Samsung sollte aber so 3GByte/s schaffen, nur natürlich nicht für 350TB, die passen da wohl kaum drauf. Insofern ist auch Deine Verschleißangst recht unbegründet. Irgendwann ist die Samsung voll und UNRAID schreibt dann eh direkt ins Array rein.

Tja, ich bin eben dabei nach dem letzten Hardwareumbau nun eien neue "Erstbefüllung" durchzuführen.

 

49 minutes ago, Michael Meiszl said:

Aber 350TB? das ist schon heftig, da brauchst Du Dir die nächsten Wochen nix vornehmen :-)))

Ja. Das Ding ist ja schon seit über einer Woche dabei.

Ich schätze, daß ich noch ca. 2 Wochen brauche, bis diese Daten angekomen sind.

Da ich aber dennoch zwischenzeitlich der Zielnutzung entgegen kommen will, ist es ab und zu erforderlich an andereen "Stellen" zu fummeln, und leider sind solche Punkte wie CPU Kernzuordnung teilweise mit Neustarts und anderen Konfigurationsänderungen verbunden.

 

 

Array-Sizer.png

Link to comment
25 minutes ago, alturismo said:

wenn du zig GB "ohne" echtes Schreiben "nur" in den RAM schieben würdest hättest du auch keinerlei "Bremse",

Wenn es in Summe nur um ein paar GB gehen würde wäre es auch kein Problem. Die sind ruckzuck weggespeichert.

 

25 minutes ago, alturismo said:

sprich, bei deinem 2.5G Netzwerk würde der Vollgas schreiben ...

Macht er auch, wenn er zur nächsten Festplatte springt (High Water) und diese im Außenbereich mit großen Dateien beschreibt.

 

Ich habe und suche aktuell ja in dieser Diskussion kein Problem. Ich fragte nur, wie ich die im Ram liegenden Cache Daten flushen kann.

Daß sich aus dieser simplen Frage Vermutungen über Netzwerkprobleme oder die Suche nach einer Bremse ergeben war von mir nicht beabsichtigt.

 

25 minutes ago, alturismo said:

und falls dein cache übrigens mit "aktiven" Daten belegt ist, bleibt beim kopieren wahrscheinlich gar nichts im cache ... wovon ich jetzt bei 128G Ram zwar nicht ausgehe ;) aber das nur am Rande erwähnt ...

Aktuell langweilt sich unraid udn es läuft (abgesehen von ein paar Plugins) nur der krusaderDocker und holt eben Daten von einem externen PC und schreibt sie ins Share (ohne NVMe/SSD Cache) direkt auf das Array (aktuell ohne Parity).

 

25 minutes ago, alturismo said:

mach doch einen spindown, und öffne danach die Datei von der physischen disk ... wenn jetzt ein spinup kommt ist die Datei nur noch auf der disk und nicht mehr im RAM, zum Beispiel einer Datei die du vor paar Minuten dahin geschoben hast ...

Das würde ja nicht klären ob die Datei geschrieben wurde, weil sie ja dennoch zusätzlich im Cache liegen könnte.

Mir geht es nicht zwingend darum den RAM Cache leer zu bekommen, sondern darum, dass alles, was dort gelagert wird eben auch geschrieben ist, spätestens, wenn ich es manuell ausgeloest haben will.

 

Link to comment
12 minutes ago, DataCollector said:

Mir geht es nicht zwingend darum den RAM Cache leer zu bekommen, sondern darum, dass alles, was dort gelagert wird eben auch geschrieben ist, spätestens, wenn ich es manuell ausgeloest haben will.

Das passiert wie gesagt nach 30 Sekunden und darauf kannst du dich blind verlassen.

 

Wenn aber in diesen 30 Sekunden etwas passiert zb ein Stromausfall, dann kommt es darauf an ob die Datei bereits von der Quelle entfernt wurde. Dateien werden beim Verschieben ja erst entfernt, wenn sie vollständig übertragen wurden. Haben sie aber in den RAM gepasst und es sind noch keine 30 Sekunden vergangen, dann sind sie bei einem Stromausfall weg. Daher empfehle ich Nutzern ohne USV den Schreibcache auf 100 MB zu reduzieren (etwas Cache braucht man, sonst geht die Performance massiv in den Keller).

 

Bzw ich sehe gerade, dass ich den Weg über das Plugin empfohlen habe und da 1% einzustellen:

https://forums.unraid.net/topic/99393-häufig-gestellte-fragen/?do=findComment&comment=959302

 

 

Bei 100GB freiem RAM sind das immer noch 1GB.

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...