Performanceoptimierung Best‐Practices

Performance-Optimierungen für Kitodo (Best Practices)

Der Artikel fußt auf dem Barcamp-Thema und entstand im Rahmen des Kitodo-Praxistreffens November 2024 in Marburg.

Initiator war das HLA, da es in der Vergangenheit erhebliche Probleme mit unzureichender Leistung und Anwendungsabbrüchen bei der Nutzung von Kitodo hatte.

Insbesondere bei der Ausführung von verschiedenen, komplexen Workflows trat vermehrt das Phänomen auf, dass selbst mit 48 GiB RAM die Maschine in die Sättigung fuhr bzw. zum stehen kam.

Während des Barcamps konnten wir zwei Bereiche lokalisieren, in denen man weitere Optimierungen hinsichtlich Leistung und damit auch Stabilität durchführen kann.

Die hier aufgezeigten Best-Practices sind lediglich Vorschläge, die größtenteils auf Erfahrungen basieren, sollten aber in eigenen Tests möglichst verifizert werden.

Optimierungen von Hardware und Systemunterbau

Hardware (phys. oder virtuell)

Grundsätzliches

Im allgemeinen gilt für Kitodo als Tomcat-Applikation: Eher mehr RAM als CPU-Kerne einzusetzen. Tomcat skaliert oft nicht gut über mehrere Kerne, sondern eher über mehr RAM.

Die nachfolgenden Anforderungen beziehen sich in erster Linie auf ein "All-In-One"-System (AIO) zu einfacheren Betrachtung

Eine Empfehlung zur Skalierung anhand von Nutzendenzahlen könnte man anhand folgender Faustformel berücksichtigen:

4 GiB RAM als Basis
plus 0.5 GiB pro Nutzende

Ein weiterer wichtiger Faktor ist natürlich die Anzahl von Workflows, Workflowschritten etc. die hier aber Eingangs nur schwer beziffert werden können. Daher werden am Ende des Dokuments weitere Beispielszenarien angefügt.

Mindestanforderungen

Generell sollte ein solches System nicht mit weniger als 4 GiB RAM pro "Rolle" ausgestattet werden, also berücksichtigen wir hierbei

Tomcat/Kitodo
Suchindex
Datenbank
Betriebssystem

dann ergeben sich für ein "vernünftiges Mittelmaß":

CPU: 2 Kerne
RAM: 16 GiB
SWAP: min. 1GiB
HDD: min. 50 GiB

Anforderungen an Systeme mit größerem Volumen/Workflowaufkommen

Für eine Konfiguration mit 4 parallelen Tasks und ca. 5 Nutzenden

CPU: 4 Kerne
RAM: 32GiB
SWAP: 5GiB
HDD:

50 GiB für /root
50 GiB für Datenbankpartition
evtl. 20 GiB für Logging

Bei Erhöhung eines Wertes für Tasks, CPU oder RAM (plus SWAP) empfiehlt es sich, die anderen Werte entsprechend anzupassen.

Denn zum Beispiel eine Erhöhung der CPU und der parallelen Tasks sorgt auch für einen erhöhten RAM-Verbrauch. (siehe dazu auch: TaskManager keepThreads Einstellungen)

Betriebssystem (allgemein)

geringen Wert für vm.swappiness einstellen z.B. 1
SSD-Storage für Betriebssystem verwenden (xx GiB)
Das System möglichst schlau partitionieren, d.h. eine Trennung von root-Partition / und /tmp, /log etc. kann Sinn machen.

JAVA

Im allgemeinen sollte der "-Xmx" Wert nicht zu hoch angesetzt werden und sich lieber von unten angenähert werden. Denn erst wenn dieser Wert erreicht ist, beginnt Java mit der Garbage Collection.

Achtung! Speziell zum Thema GarbageCollection:

Hier hat sich der Einsatz des G1C1-GarbageCollectors als förderlich erwiesen. Dieser scheint seinen Job um einiges effizienter zu erledigen als andere GCs. Konfig-Optionen dazu s.u. in der systemd-Datei

Tomcat

Es empfiehlt sich die standardmäßig mitgelieferte tomcat9 Systemd-Service-Date` durch eine eigene zu überschreiben, um in dieser Anpassungen vornehmen zu könne, welche über Updates hinweg erhalten bleiben.

Am einfachsten ist es hierbei, die mitgelieferte systemd-Datei als Vorlage zu verwenden.

Diese befindet sich unter /lib/systemd/system/tomcat9.service

Im folgenden werden nur die Performancebezogenen Abweichungen erwähnt:

[Service]

# Configuration
...

Environment="CATALINA_OPTS=-Xms4g -Xmx16g -Xss1m -server -XX:MaxMetaspaceSize=256m -XX:PermSize=512m -XX:+UseStringDeduplication -XX:+ExitOnOutOfMemoryError -XX:+UseG1GC -XX:MaxGCPauseMillis=1000 -XX:ParallelGCThreads=4"

Environment="JAVA_OPTS=-Djava.awt.headless=true -Xms64M -Xmx5g -Dfile.encoding=UTF-8"

...

Elasticsearch (wenn auf gleicher VM / AIO)

Beschränken der RAM-Zuweisung an Elasticsearch:

Erstellen einer neuen Datei unterhalb von /etc/elasticsearch/jvm.options.d/ z.B. mit dem Namen "ram.options"
Füllen der Datei mit dem folgendem Inhalt, um Elasticsearch auf 8GiB RAM zu beschränken:

-Xms8g
-Xmx8g

Hintergrund: Elasticsearch benutzt standardmäßig die Hälfte des RAMs. Bei einer größeren High-Available Clusterlösung von Elasticsearch wird dies vermutlich auch sinnvoll sein, im Kitodo-Kontext kann dies aber limitiert werden.

Datenbank

Es SOLLTE eine von Kitodo unterstützte Datenbanksoftware z.B. MariaDB verwendet werden. (Nachfolgende Empfehlungen beziehen sich hauptsächlich auf diese)
Es sollte InnoDB verwendet werden. (Dies sollte bei Neuinstallation bereits Standard sein)
Erstellen von Indizes auf entsprechende Tabellen / Spalten / Werte. ACHTUNG: Dies sollte NUR für ausgewählte Felder umgesetzt werden, da dies ansonsten sehr schnell viel zu groß werden kann!
Um entsprechende Abfragen herauszufinden kann der "slow query log" verwendet werden.
Der sogenannte MySQLTuner könnte hierbei behilflich sein: https://github.com/major/MySQLTuner-perl

Anwendungsbezogene Optimierungen

TaskManager keepThreads Einstellungen

In den kitodo_config.properties gibt es einen Abschnitt über den "Task manager". In diesem befinden sich unter anderem die folgenden 4 Einstellungsmöglichkeiten:

taskManager.keepThreads.failed.count=1
taskManager.keepThreads.failed.minutes=5
taskManager.keepThreads.successful.count=1
taskManager.keepThreads.successful.minutes=2

Je niedriger man diese Werte setzt, desto schneller werden erfolgreich / fehlgeschlagene Aufgaben (threads) wieder freigegeben und können dann durch den Garbage Collector aufgeräumt werden.

Dies sorgt aber auch dafür, dass die Aufgaben schnell wieder aus der Taskmanager Übersicht verschwinden, also man ggf nicht direkt sieht, ob eine Aufgabe erfolgreich war oder fehlgeschlagen ist.

Man sollte diese Werte so wählen, dass es für den eigenen Einsatzzweck passt.

Script-Tasks

Die Ausführungszeit von Scripten über Kitodo sollte möglichst kurz gehalten werden.
Bei langlaufenden Scripten sollten diese nur über Kitodo inital gestartet, dann aber nicht weiter ausgeführt werden. Hierbei empfiehlt es sich eine Art von Queue zu verwenden bzw. mit Hilfe von ActiveMQ die Aufgaben im Nachgang über das Script schließen zu lassen.
Achtung: Das Logging kann u.U. das System ausbremsen, wenn man alle Scripte in die kitodo.log schreiben lässt. Der gleichzeitige Zugriff kann bei hoher Schreibfrequenz zu einer Blockade führen! Eine Lösung kann sein, die Scripte jeweils eigene Logs schreiben zu lassen.