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.

Häufig gestellte Fragen

Wann sollte ich in Znuny von RuntimeDB auf StaticDB wechseln?

StaticDB lohnt sich ab etwa 80.000 offenen Tickets, wenn Sie konstante Abfragezeiten statt des linearen Anstiegs bei RuntimeDB brauchen.

Ist Elasticsearch für die Znuny-Volltextsuche Pflicht?

Nein. Znuny hat einen internen Volltextindex; Elasticsearch ist optional bei sehr großen Datenmengen (z. B. mehr als etwa 10 Millionen Artikel).

Wie hilft Ticket-Archivierung der Znuny-Performance?

Archivierung reduziert aktiv indexierte Tickets, sodass Queue-Ansichten und Suchen auf großen Installationen schneller bleiben.