Znuny – Performance Optimierung

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: otobo-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.