Performanceoptimierung Best‐Practices

Hallo und Gruß!

Hier entsteht der Wiki-Artikel zum Thema

Performance-Optimierungen für Kitodo

auf Basis des Barcamps im Rahmen des KITODO-Praxistreffens in Marburg November 2024.

Das Barcamp-Thema entstand aus den Erfahrungen des HLA mit unzureichender Leistung und Anwendungsabbrüchen von KITODO bei der Ausführung von verschiedenen Workflows.

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

Eine Information vorab: Dies sind Best-Practies Empfehlungen(!). Diese können genau so auch für andere funktionieren, aber man sollte die Einstellung nicht ungeprüft übernehmen. Es sind eher Richtwerte, an denen sich orientiert werden kann. Diese ersetzen aber keine Tests!

Optimierungen von Hardware und Systemunterbau

Hardware (phys. oder virtuell)

Im allgemeinen gilt für Kitodo / Tomcat: RAM > CPU

größeres System (im Aufbau) mit mehreren parallelen Task (4) [am Beispiel des HLA]

CPU: 4
RAM: 32GiB
SWAP: 5GiB

Bei Erhöhung eines Wertes 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

Diese sind eher allgemein als Kitodo bezogen:

geringer Wert für vm.swappiness z.B. 1
SSD für Betriebssystem verwenden

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.

Tomcat

Es empfiehlt sich die standardmäßig mitgelieferte tomcat9 Systemd Service Datei 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.