[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:
