Znuny – Performance Optimierung

In diesem tiefgehenden Leitfaden behandeln wir alle relevanten Ebenen für eine skalierbare und performante Znuny-Installation:

1. Index-Module für Ticket-Queues
2. Volltext- und Dokumentensuche (intern & Elasticsearch)
3. Artikelspeicher-Backends (DB vs. FS)
4. Ticket-Archivierung
5. Caching (Redis, Ramdisk)
6. Datenbank-Tuning (MySQL/MariaDB)
7. Hardware & Infrastruktur
8. Automatisierung (Cron, Docker-Compose Scripts)
9. Monitoring & Alerts

1. Ticket-Indexmodul

1.1 RuntimeDB (Standard)

• Modul: Kernel::System::Ticket::IndexAccelerator::RuntimeDB
• Funktionsweise: Dynamische Abfragen direkt auf ticket-Tabelle
• Einsatzbereich: Bis ~60k offene Tickets ohne spürbare Latenz
• Metrik: Query-Time ∝ Ticket-Anzahl ➔ linearer Anstieg

1.2 StaticDB (High-Scale)

• Modul: Kernel::System::Ticket::IndexAccelerator::StaticDB
• Funktionsweise: Vorkompilierte ticket_index-Tabelle mit Token-Spalten (Betreff, Status, Owner u.v.m.)
• Einsatzbereich: >80k offene Tickets, konstante Abfragezeiten
• Initiale Indizierung: Kernel::System::Ticket::IndexAccelerator::RuntimeDB
• Cron-Beispiel: Täglicher Rebuild um 02:30 Uhr ticket
• Optimierungstipps:
  • Automatische Teil-Rebuilds nur für geänderte Queues (SysConfig-Option)
  • Monitoring der Laufzeit: messen via time-Kommando

2. Volltext-Suche & Dokumentensuche

2.1 Interner Volltextindex

• Kommando für Rebuild: Kernel::System::Ticket::IndexAccelerator::StaticDB
• Empfohlene SysConfig:

  Einstellung	Wert	Zweck
  Ticket::SearchIndex::IndexArchivedTickets	0 (aus)	Archivierte Tickets ausschließen
  Ticket::SearchIndex::Attribute.WordCountMax	1000	Erste 1000 Wörter indexieren
  Ticket::SearchIndex::Filters	Standard	Regex-Filter für Sonderzeichen
  Ticket::SearchIndex::StopWords###Custom	de, en	Eigene Stopwords ergänzen

• Beispiel-Filter (SysConfig unter Filters): ticket_index

2.2 Elasticsearch (optional)

Für große Datenmengen (>10M Artikel) wird Elasticsearch empfohlen.

2.2.1 JVM-Heap-Größe

time

• Setze Min = Max um GC-Pausen zu minimieren
• Max ≤ 50% des physischen RAM

2.2.2 Disk Watermarks

keyword

• low/high für Shard-Allokation
• flood_stage setzt Indizes read-only

2.2.3 Mapping-Optimierungen

• keyword-Typ für selten geänderte Felder (z. B. Ticket-IDs)
• text + analyzer für Freitext

3. Artikelspeicher-Backends

Backend	Speicherort	Einsatz
DB	MySQL/MariaDB	< 10k Anhänge, Single-Server
FS	lokales FS / NFS / SAN	≥ 10k Anhänge, Multi-Server, hohe IOPS

3.1 Wechsel DB ↔ FS

text

• Prüfe /opt/znuny/var/log/article_storage.log
• Achte auf Berechtigungen: Nutzer znuny (UID 1000)

4. Ticket-Archivierung

Reduziert aktiv indexierte Datensätze.

1. SysConfig: Ticket::ArchiveSystem = 1
2. GenericAgent-Job einrichten:
   • Limit: max. 5000 Tickets pro Lauf
   • Filter: State = close UND Changed < now-6mon
3. Cron (wöchentlich Mo 4:00 Uhr): analyzer

5. Caching

5.1 Redis-Cache

1. Installation: /opt/znuny/var/log/article_storage.log
2. Perl-Modul: cpan install Redis::Fast
3. SysConfig: znuny

5.2 Ramdisk für /opt/znuny/var/tmp

Ticket::ArchiveSystem = 1

6. Datenbank-Tuning (MySQL/MariaDB)

Bearbeite /etc/my.cnf.d/znuny.cnf: State = close

• Benchmark: TPC-C oder sysbench für Lasttests

7. Hardware & Infrastruktur

• CPU: ≥ 8 Cores für Parallelität
• RAM: Ausreichend für DB-Pool + JVM + Caches
• Storage: NVMe-SSDs in RAID10 (≥ 10k IOPS)
• Netzwerk: 10 GbE zwischen Frontend & DB
• Load-Balancer: HAProxy oder NGINX mit Health-Checks

8. Automatisierung & Monitoring-Skripte

8.1 Performance-Monitoring

Script: /usr/local/bin/znuny_monitor.sh Changed < now-6mon Cron (stündlich): cpan install Redis::Fast

8.2 Aufräumen alter Logs

/opt/znuny/var/tmp Cron: täglich 1:00 Uhr

9. Monitoring & Alerts

• Prometheus Exporter: znuny-agent Metriken (ResponseTime, QueueDepth)
• Grafana Dashboard:
  • Query-Latenz (95th percentile)
  • Redis-Cache-Hits vs. Misses
  • InnoDB Buffer Pool Usage
  • Elasticsearch Shard-Status
• Alert Rules:
  • Slow Queries > 200 ms für > 5 min
  • Disk-Watermark > 90%
  • Heap-Pausen > 100 ms
  • DB Connections > 80% von max_connections

Fazit

Mit diesem umfassenden Performance-Tuning-Plan auf Index-, Such-, Storage-, Cache-, Datenbank- und Infrastruktur-Ebene erreichen Sie in Znuny eine stabile und schnelle Plattform, die auch bei Millionen von Tickets und Artikeln reibungslos skaliert.

Znuny Health-Check & Performance-Tuning

Lange Ladezeiten oder hohe Serverlast? Wir optimieren Datenbankabfragen, Indizes, Caching und den Znuny-Daemon für spürbar schnellere Reaktionszeiten.

Performance-Audit buchen

Häufig gestellte Fragen

Wann sollte ich in Znuny von RuntimeDB auf StaticDB wechseln und wie konfiguriere ich es?

Der Wechsel von RuntimeDB auf StaticDB in Znuny ist entscheidend für die Performance bei großen Ticketmengen. Während RuntimeDB (Modul Kernel::System::Ticket::IndexAccelerator::RuntimeDB) dynamische Abfragen direkt auf der ticket-Tabelle durchführt und bis etwa 60.000 offene Tickets ohne spürbare Latenz auskommt, steigt die Abfragezeit hier linear mit der Ticketanzahl. StaticDB (Modul Kernel::System::Ticket::IndexAccelerator::StaticDB) hingegen ist für Installationen mit über 80.000 offenen Tickets konzipiert und bietet konstante Abfragezeiten. Es nutzt eine vorkompilierte ticket_index-Tabelle mit Token-Spalten für Betreff, Status, Owner und weitere Attribute.

Die initiale Indizierung erfolgt durch Ausführung des Rebuild-Kommandos, und ein täglicher Rebuild, beispielsweise um 02:30 Uhr via Cron, ist empfehlenswert, um die Index-Tabelle aktuell zu halten. Für weitere Optimierung können automatische Teil-Rebuilds nur für geänderte Queues in der SysConfig aktiviert werden. Die Laufzeit des Rebuilds sollte mittels des time-Kommandos überwacht werden, um Performance-Engpässe zu identifizieren.

Quellen:

• OTOBO Performance Optimization – Scaling for High Ticket Volume
• Znuny Documentation

Ist Elasticsearch für die Znuny-Volltextsuche Pflicht und wann ist es sinnvoll?

Nein, Elasticsearch ist für die Volltextsuche in Znuny nicht zwingend erforderlich. Znuny verfügt über einen internen Volltextindex, der für die meisten Installationen ausreichend ist. Dieser interne Index kann bei Bedarf neu aufgebaut werden und bietet Konfigurationsmöglichkeiten über die SysConfig, um beispielsweise archivierte Tickets auszuschließen (Ticket::SearchIndex::IndexArchivedTickets = 0), die Anzahl der zu indexierenden Wörter zu begrenzen (Ticket::SearchIndex::Attribute.WordCountMax = 1000) oder eigene Stopwords zu definieren.

Elasticsearch wird erst bei sehr großen Datenmengen, typischerweise ab mehr als 10 Millionen Artikeln, empfohlen. In solchen Szenarien kann Elasticsearch die Suchperformance erheblich verbessern. Bei der Implementierung von Elasticsearch sind Optimierungen wie die Einstellung der JVM-Heap-Größe (Min=Max, Max ≤ 50% des physischen RAM) und die Konfiguration von Disk Watermarks wichtig. Zudem sollten Mapping-Optimierungen vorgenommen werden, indem keyword-Typen für selten geänderte Felder (z. B. Ticket-IDs) und text mit analyzer für Freitextfelder verwendet werden, um die Effizienz der Suche zu maximieren.

Quellen:

• OTOBO Performance Optimization – Scaling for High Ticket Volume
• Znuny Documentation

Welche Artikelspeicher-Backends gibt es in Znuny und wann sollte ich welches verwenden?

Znuny bietet zwei primäre Backends für die Speicherung von Artikelanhängen: die Datenbank (DB) und das Dateisystem (FS). Die Wahl des richtigen Backends ist entscheidend für die Performance, insbesondere bei der Handhabung von Anhängen.

• Datenbank (DB): Dieses Backend speichert Anhänge direkt in der MySQL/MariaDB-Datenbank. Es ist empfehlenswert für kleinere Installationen mit weniger als 10.000 Anhängen und in Single-Server-Umgebungen, da es die Verwaltung vereinfacht und keine zusätzlichen Dateisystem-Berechtigungen erfordert.
• Dateisystem (FS): Bei Installationen mit 10.000 oder mehr Anhängen oder in Multi-Server-Umgebungen mit hohen IOPS-Anforderungen ist das Dateisystem-Backend die bessere Wahl. Hier werden die Anhänge auf einem lokalen Dateisystem, NFS oder SAN gespeichert. Dies entlastet die Datenbank und ermöglicht eine bessere Skalierbarkeit der Speicherressourcen.

Ein Wechsel zwischen DB und FS ist möglich und sollte sorgfältig geplant werden. Nach einem Wechsel ist es wichtig, das Logfile /opt/znuny/var/log/article_storage.log auf Fehler zu überprüfen und sicherzustellen, dass der znuny-Benutzer (UID 1000) die korrekten Dateisystemberechtigungen besitzt, um auf die Anhänge zugreifen zu können.

Quellen:

• OTOBO Performance Optimization – Scaling for High Ticket Volume
• Znuny Documentation

Wie trägt die Ticket-Archivierung zur Znuny-Performance bei und wie richte ich sie ein?

Die Ticket-Archivierung ist ein effektives Mittel, um die Performance von Znuny zu optimieren, indem sie die Anzahl der aktiv indexierten Datensätze reduziert. Dies führt zu schnelleren Queue-Ansichten und Suchergebnissen, insbesondere in großen Installationen. Wenn Tickets archiviert werden, werden sie aus den primären Indizes entfernt, bleiben aber weiterhin zugänglich, falls sie benötigt werden.

Um die Ticket-Archivierung zu aktivieren und zu konfigurieren, sind folgende Schritte notwendig:

1. SysConfig: Setzen Sie die Einstellung Ticket::ArchiveSystem auf 1, um die Archivierungsfunktion global zu aktivieren.
2. GenericAgent-Job: Richten Sie einen GenericAgent-Job ein, der regelmäßig alte Tickets archiviert. Es wird empfohlen, ein Limit von maximal 5000 Tickets pro Lauf zu setzen, um die Systemlast zu kontrollieren. Ein sinnvoller Filter könnte State = close UND Changed < now-6mon sein, um alle geschlossenen Tickets, die älter als sechs Monate sind, zu archivieren.
3. Cron-Job: Planen Sie die Ausführung des GenericAgent-Jobs über einen Cron-Job, beispielsweise wöchentlich am Montag um 4:00 Uhr, um eine regelmäßige Wartung zu gewährleisten.

Durch diese Maßnahmen bleibt Ihre Znuny-Installation auch bei wachsendem Ticketvolumen performant und reaktionsschnell.

Quellen:

• OTOBO Performance Optimization – Scaling for High Ticket Volume
• Znuny Documentation

Was sollte ich über die Implementierung und Konfiguration des Redis-Cache in Znuny wissen?

Der Redis-Cache kann die Performance von Znuny erheblich verbessern, indem er häufig angefragte Daten im Arbeitsspeicher vorhält und somit Datenbankzugriffe reduziert. Dies ist besonders vorteilhaft für dynamische Inhalte und Session-Daten.

Die Implementierung des Redis-Cache in Znuny umfasst mehrere Schritte:

1. Installation von Redis: Stellen Sie sicher, dass der Redis-Server auf Ihrem System installiert und korrekt konfiguriert ist. Die genauen Installationsschritte hängen von Ihrem Betriebssystem ab.
2. Perl-Modul: Installieren Sie das notwendige Perl-Modul Redis::Fast über CPAN. Dies kann in der Regel mit dem Befehl cpan install Redis::Fast erfolgen. Dieses Modul ermöglicht Znuny die Kommunikation mit dem Redis-Server.
3. SysConfig-Einstellungen: Nehmen Sie die entsprechenden Konfigurationen in der Znuny SysConfig vor. Hier müssen Sie Redis als Caching-Backend aktivieren und die Verbindungsparameter zum Redis-Server definieren. Dies beinhaltet typischerweise die Angabe des Hosts und Ports des Redis-Servers.

Durch die korrekte Einrichtung des Redis-Cache können Sie die Reaktionszeiten Ihrer Znuny-Installation deutlich verkürzen und die Datenbanklast reduzieren, was zu einer insgesamt flüssigeren Benutzererfahrung führt.

Quellen:

• OTOBO Performance Optimization – Scaling for High Ticket Volume
• Znuny Documentation

Welche Empfehlungen gibt es für das Datenbank-Tuning von MySQL/MariaDB in Znuny?

Ein gut abgestimmtes Datenbank-Backend ist das Herzstück einer performanten Znuny-Installation. Für MySQL oder MariaDB gibt es spezifische Tuning-Empfehlungen, die in der Konfigurationsdatei /etc/my.cnf.d/znuny.cnf vorgenommen werden sollten.

Wichtige Parameter, die angepasst werden müssen, umfassen:

• innodb_buffer_pool_size: Dies ist der wichtigste Parameter. Er sollte so groß wie möglich sein, idealerweise 70-80% des verfügbaren RAMs, um häufig genutzte Daten und Indizes im Speicher zu halten.
• max_connections: Legt die maximale Anzahl gleichzeitiger Datenbankverbindungen fest. Dieser Wert sollte an die erwartete Last und die Anzahl der Znuny-Prozesse angepasst werden.
• query_cache_size: Kann für bestimmte Workloads nützlich sein, ist aber in modernen MySQL/MariaDB-Versionen oft weniger relevant oder sogar kontraproduktiv. Eine sorgfältige Bewertung ist hier angebracht.
• log_bin / sync_binlog: Für Replikation und Datenintegrität wichtig, kann aber die Performance beeinflussen.
• innodb_flush_log_at_trx_commit: Beeinflusst die Haltbarkeit von Transaktionen und die Performance. Ein Wert von 2 kann die Performance verbessern, birgt aber ein geringes Risiko bei Systemabstürzen.

Es ist unerlässlich, die Datenbank-Performance regelmäßig zu überwachen und Lasttests (z.B. mit TPC-C oder sysbench) durchzuführen, um die Auswirkungen der Änderungen zu bewerten und die Konfiguration kontinuierlich zu optimieren.

Quellen:

• OTOBO Performance Optimization – Scaling for High Ticket Volume
• Znuny Documentation