Anzahl der Zookeeper-Logfiles bschränken

NorbertK · 18. April 2023

Hallo zusammen,
Wir haben Installationen, bei denen eine große Anzahl ".log"-Dateien im zookeeper zu finden sind. Zum Beispiel auch in Musterfirma-VMs

Das sind leider Transaktionslogs, die nicht einfach gelöscht werden können.

Wie kann die Agorum-Zookeper-Installation so angepasst werden, dass diese Dateien automatisch weggeräumt werden?

Ich habe auch schon selbst in den Konfigurationsdateien herumgespielt. Leider hat mich der Zookeeper ignoriert.

Letztendlich habe ich SOLR und den Zookeeper neu installiert.

Das ist besonders bei Docker-Containern unangenehm.
Wie viel Platz dabei verloren gehen kann, sieht man daran, das die Logs im Tar-GZ auf bis zu 5% eingedampft werden.

Grüße

Norbert

Dominik.agorum · 18. April 2023

Hallo Norbert,

wir werden uns dein Problem anschauen und versuchen so schnell es geht eine Lösung zu finden.

Liebe Grüße

Dominik

Dominik Katzenmaier · 31. August 2023

Guten Morgen!

Ich möchte dieses Thema mal aufgreifen, denn dieses Zookeeper-Verhalten ist wirklich ziemlich doof für die Datensicherung. Unsere Produktivumgebung ist ebenfalls gedockert, das Docker-Volume welches die Zookeeper-Daten enthält ist ein Bind Mount, sodass die Zookeeper Dateien im Endeffekt im Dateisystem des Docker-Host liegen. Hierbei handelt es sich eine ext4-Partition.

Bei ext4 nutzt Zookeeper offenbar irgendwelche Techniken des Dateisystems, damit die Dateien im Dateisystem deutlich weniger phyischen Speicherplatz belegen, als sie vorgeben.

Außerhalb des data-Ordner ist mit du ist zu sehen, dass nur 92MB phyischer Speicherplatz benötigt wird:

Code

[root@1a0a7df858a3 zookeeper]# cd /opt/agorum/agorumcore/zookeeper/data/
[root@1a0a7df858a3 data]# du -sh *
92M     version-2
4.0K    zookeeper_server.pid

Schauen wir uns die Dateien mit ls im version-2-Ordner an, sehen wir jedoch, dass jede Datei so aussieht, als sei sie 64MB groß.

Code

.......
-rw-r--r-- 1 root root 67108880 Aug  3 03:04 log.6daf
-rw-r--r-- 1 root root 67108880 Aug  3 06:59 log.6dc8
-rw-r--r-- 1 root root 67108880 Aug  4 03:04 log.6de4
-rw-r--r-- 1 root root 67108880 Aug  4 06:59 log.6dfd
-rw-r--r-- 1 root root 67108880 Aug  5 03:04 log.6e19
-rw-r--r-- 1 root root 67108880 Aug  5 06:59 log.6e32
-rw-r--r-- 1 root root 67108880 Aug  6 03:04 log.6e4e
-rw-r--r-- 1 root root 67108880 Aug  6 06:59 log.6e67
-rw-r--r-- 1 root root 67108880 Aug  7 03:04 log.6e83
-rw-r--r-- 1 root root 67108880 Aug  7 03:06 log.6e8b
-rw-r--r-- 1 root root 67108880 Aug  7 06:59 log.6ea2
-rw-r--r-- 1 root root 67108880 Aug  8 03:04 log.6ebe
-rw-r--r-- 1 root root 67108880 Aug  8 06:59 log.6ed7
-rw-r--r-- 1 root root 67108880 Aug  9 03:04 log.6ef3
-rw-r--r-- 1 root root 67108880 Aug  9 06:59 log.6f0c
-rw-r--r-- 1 root root 67108880 Aug 10 03:04 log.6f28
-rw-r--r-- 1 root root 67108880 Aug 10 04:09 log.6f41
-rw-r--r-- 1 root root 67108880 Aug 10 06:59 log.6f49
-rw-r--r-- 1 root root 67108880 Aug  9  2021 log.6f5
-rw-r--r-- 1 root root 67108880 Aug 11 03:04 log.6f63
-rw-r--r-- 1 root root 67108880 Aug 11 06:59 log.6f7c
-rw-r--r-- 1 root root 67108880 Aug 12 03:04 log.6f98
-rw-r--r-- 1 root root 67108880 Aug 12 06:59 log.6fb1
-rw-r--r-- 1 root root 67108880 Aug 13 03:04 log.6fcd
-rw-r--r-- 1 root root 67108880 Aug 13 06:59 log.6fe6
-rw-r--r-- 1 root root 67108880 Aug 14 03:04 log.7002
-rw-r--r-- 1 root root 67108880 Aug 14 06:59 log.701b
-rw-r--r-- 1 root root 67108880 Aug 15 03:04 log.7037
-rw-r--r-- 1 root root 67108880 Aug 15 06:59 log.7050
-rw-r--r-- 1 root root 67108880 Aug 16 03:04 log.706c
-rw-r--r-- 1 root root 67108880 Aug 16 06:59 log.7085
-rw-r--r-- 1 root root 67108880 Aug 17 03:04 log.70a1
-rw-r--r-- 1 root root 67108880 Aug 17 06:59 log.70ba
-rw-r--r-- 1 root root 67108880 Aug 18 03:04 log.70d6
-rw-r--r-- 1 root root 67108880 Aug 18 06:59 log.70ef
-rw-r--r-- 1 root root 67108880 Aug 18 16:42 log.710b
-rw-r--r-- 1 root root 67108880 Aug 18 16:45 log.7124
-rw-r--r-- 1 root root 67108880 Aug 18 16:48 log.712c
-rw-r--r-- 1 root root 67108880 Aug 18 20:59 log.7143
-rw-r--r-- 1 root root 67108880 Aug  9  2021 log.715
-rw-r--r-- 1 root root 67108880 Aug 18 21:20 log.715c
-rw-r--r-- 1 root root 67108880 Aug 18 21:22 log.7161
-rw-r--r-- 1 root root 67108880 Aug 19 03:04 log.717b
-rw-r--r-- 1 root root 67108880 Aug 19 06:59 log.7194
-rw-r--r-- 1 root root 67108880 Aug 19 17:18 log.71b0
.......

Alles anzeigen

Welche ext4-Magie Zookeeper da für dieses Phänomen verwendet macht weiß ich genauso wenig wie unsere Backup-Software . Die sichert nämlich stets die 64MB pro Datei. Und von denen haben wir im Produktivsystem mittlerweile 1092 Stück. Das macht aktuell: 1092 * 64MB / 1024 = 68GB Overhead im Backup, Tendenz steigend. Und dieser würde im Restore-Fall auch wieder zurückgespielt werden.

Uns ist dieses Problem bereits seit 1,5 Jahren bekannt und wir standen bereits mit dem Agorum-Support in Kontakt. Wir hatten zuletzt die Empfehlung erhalten folgende (die letzten 4 Zeilen) Einstellungen in der zoo.cfg zu tätigen, die wohl von Agorum mittlerweile getestet und freigegeben wurden:

Code

tickTime=2000
dataDir=/opt/agorum/agorumcore/jboss/server/default/../../../zookeeper/data
clientPort=9981
minSessionTimeout=60000
maxSessionTimeout=120000
snapCount=100
preAllocSize=1M
autopurge.snapRetainCount=3
autopurge.purgeInterval=12

Das ist nun ziemlich genau 7 Tage her, bisher haben sich die Log-Dateien noch nicht reduziert. Müssen wir einfach noch länger warten oder hätte sich in der Zeit schon etwas tun müssen?

Oliver Kaufmann · 31. August 2023

Guten Morgen Herr Katzenmaier,

ich kann mich an den Vorgang erinnern, nach unserer Freigabe habe ich jedoch keine Rückmeldung Ihrerseits erhalten, dass die Änderung sich bis heute nicht bemerkbar gemacht hat. Bitte teilen Sie uns die Ergebnisse Ihrer Beobachtung im ursprünglichen Ticket mit. Hierzu müssen Sie lediglich auf eine vorhandene Ticket-Mail antworten. Der Vorgang wird dann erneut eröffnet.

Vielen Dank!

Dominik Katzenmaier · 31. August 2023

Ok, machen wir so

Aber sicherlich ist dieses Zookeeper-"Phänomen" auch für andere noch Agorum-Admins interessant zu wissen

volker.trotte · 1. September 2023

Ja, mich würde das auch interessieren

Oliver Kaufmann · 1. September 2023

Dominik Katzenmaier, ganz bestimmt und wir werden, wie immer, die Erkenntnisse aus gelösten Vorgängen in unsere Doku für alle einfließen lassen. Ihr Ticket liegt seit gestern in der Entwicklung. Sobald ich eine Antwort für Sie habe, melde ich mich im Vorgang bei Ihnen.

bkl-isos.de · 13. Mai 2024

Hinweis: die großen "log.abc" - Files (siehe Abbildung in #3) sind laut "roi" keine Logdateien, sondern enthalten die Index-Daten für solr! Diese sollte man auf keinen Fall löschen. Eventuell gibt es ja noch irgendeine andere Möglichkeit, um den Speicherplatz zu reduzieren.

volker.trotte · 13. Mai 2024

Zitat von bkl-isos.de

Hinweis: die großen "log.abc" - Files (siehe Abbildung in #3) sind laut "roi" keine Logdateien, sondern enthalten die Index-Daten für solr! Diese sollte man auf keinen Fall löschen. Eventuell gibt es ja noch irgendeine andere Möglichkeit, um den Speicherplatz zu reduzieren.

Das dürfte die transaction logs für zookeper sein:

The Log Directory

The Log Directory contains the ZooKeeper transaction logs. Before any update takes place, ZooKeeper ensures that the transaction that represents the update is written to non-volatile storage. A new log file is started each time a snapshot is begun. The log file's suffix is the first zxid written to that log.

https://zookeeper.apache.org/d…than%20the%20data%20files.

bstrebel · 8. Juni 2024

Zum Zookeeper selbst kann ich nicht viel beitragen. Aber bzgl. der "ext4-Magie" zum sparen von Plattenplatz würde ich mir mal Sparse Files anschauen...

Anzahl der Zookeeper-Logfiles bschränken

The Log Directory

Jetzt Teil von agorum Community werden!

Teilen

Tags