[Garbage Collection] RAM Cache Verhalten seit Update 3.4 Bug?
- Thread starter Lun4r
- Start date
Abschließende in Kurzform und vereinfacht:
Haupterkenntnis -> das nächste mal richtig bauen auf ZFS mit entsprechend dimensionieten ARC- und L2ARC-Caches.
Nebenerkenntnise:
In Woche 1-4 sind keine Re-Verifys reingelaufen weil ich die Reverifyzeit angehoben habe, um 30 Tage, zum testen .
Pünktlich knallt dann in Woche 5 der Reverify voll mit rein und verzögert ind er Woche drauf die GC´s am Montag.
(Alle anderen GC-Schwankungen sind auf interne Datenschuppsereien zurückzuführen.)
Legende:
Verlauf:
Aus meiner Sicht kann das Ticket damit zu.
Danke für eure Zeit und Hinweise. =)
Noch als Zugabe die Linuxinterne RAM Belegung inkl. der Ausschläge im Cache+Buffer durch die Re-Verifys.
Man könnte also noch mit dem nötigen Kleingeld testen ob man diese Peaks mit noch mehr RAM neutralisieren kann aber dazu fehlt gerade Zeit und Geld -> ebenso ist der Leidensdruck so sehr minimiert das es keine Prio hat.
Haupterkenntnis -> das nächste mal richtig bauen auf ZFS mit entsprechend dimensionieten ARC- und L2ARC-Caches.
Nebenerkenntnise:
- RAM-Aufrüstung von 64 auf 128GB hat dazugeführt das Caches später oder gar nicht überschrieben werden und damit mehr Daten für den GC vorgehalten werden können -> Linux interne RAM Verwaltung
- Dies wird aber durch Re-Verifys "unterlaufen" weil dabei natürlich viele alte (Meta-)Daten gelesen werdenn und somit aktuelle (Meta-)Daten überschrieben werden im RAM -> Der GC liest alle aktuellen Daten der VM´s ein -> diese bzw. deren Positionen sind dann nicht mehr im RAM vorhanden und müssen neu eingelesen werden -> GC dauert länger
- Lässt man täglich nur Prune und GC´s laufen und keine Verifys bleibt die GC´s Zeit entsprechend kurz und ohne nennenswerte Schwankungen, da durch die Backups ja immer die aktuellsten (Meta-)Daten im RAM liegen
- Ebenso verhält es sich wenn man Verifys ! ohne Re-Verifys ! laufen lässt. hier liegt die Schwankung dann bei vlt. 0-10% längerer Laufzeit am Tag nach dem Verify, hier werden ja auch nur die aktuellsten Sicherungen eingelesen -> also ebenfalls das gleiche was der GC anfasst
- Sobald aber Re-Verifys mit reinlaufen erhöht sich die GC Zeit entsprechend um ein vielfaches (>300% längere Laufzeit).
- Verify mit Re-Verify der täglich gesicherten VM´s nur Samstag Vormittag.
- Verify mit Reverify der täglichen und stündlichen VM´s nur von Samstag Abend auf Sonntag.
- Hier könnte man die täglichen noch rauskannten um mehr Puffer zu haben da dann nur dessen Samstagsbackups unverifiziert aufs Band laufen würden
- Montag Nacht Tapeout
- Kein GC am WE -> nur unter der Woche
In Woche 1-4 sind keine Re-Verifys reingelaufen weil ich die Reverifyzeit angehoben habe, um 30 Tage, zum testen .
Pünktlich knallt dann in Woche 5 der Reverify voll mit rein und verzögert ind er Woche drauf die GC´s am Montag.
(Alle anderen GC-Schwankungen sind auf interne Datenschuppsereien zurückzuführen.)
Legende:
Verlauf:
Aus meiner Sicht kann das Ticket damit zu.
Danke für eure Zeit und Hinweise. =)
Noch als Zugabe die Linuxinterne RAM Belegung inkl. der Ausschläge im Cache+Buffer durch die Re-Verifys.
Man könnte also noch mit dem nötigen Kleingeld testen ob man diese Peaks mit noch mehr RAM neutralisieren kann aber dazu fehlt gerade Zeit und Geld -> ebenso ist der Leidensdruck so sehr minimiert das es keine Prio hat.
Last edited:
ARC ist OK, aber L2ARC bringt dir beim PBS nicht viel. Ich weiß nicht ob die Vorträge von der Veranstaltung gestern bei Tuxis auch online gehen, da wird das Thema schön mit Graphen und Zahlen aufgearbeitet.
Das einzige was deutliche Performance beim PBS bringt, ist ein Special Device.