OTOBO / Znuny – Performance Optimierung

In diesem tiefgehenden Leitfaden behandeln wir alle relevanten Ebenen für eine skalierbare und performante OTOBO- bzw. 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:

  /opt/otobo/bin/otobo.Console.pl Maint::Ticket::QueueIndexRebuild

• Cron-Beispiel: Täglicher Rebuild um 02:30 Uhr

  30 2 * * * /opt/otobo/bin/otobo.Console.pl Maint::Ticket::QueueIndexRebuild --force >> /var/log/otobo/queueindex.log 2>&1

• 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:

  /opt/otobo/bin/otobo.Console.pl Maint::Ticket::FulltextIndex --rebuild

• 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):

  s#[,\&<>?"!*\|;\[\]()\+\$\^=]# #g   # Sonderzeichen entfernen
  s#\b\S{1,2}\b##g                       # Wörter <3 Zeichen löschen

2.2 Elasticsearch (optional)

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

2.2.1 JVM-Heap-Größe

# jvm.options
-Xms4g
-Xmx4g

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

2.2.2 Disk Watermarks

cluster.routing.allocation.disk.watermark.low: "85%"
cluster.routing.allocation.disk.watermark.high: "90%"
cluster.routing.allocation.disk.watermark.flood_stage: "95%"

• 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

/opt/otobo/bin/otobo.Console.pl Admin::Article::StorageSwitch --target ArticleStorageFS

• Prüfe /opt/otobo/var/log/article_storage.log
• Achte auf Berechtigungen: Nutzer otobo (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):

   0 4 * * 1 /opt/otobo/bin/otobo.Console.pl Maint::Ticket::Archive --criteria State:close,Changed:-6m >> /var/log/otobo/archive.log

5. Caching

5.1 Redis-Cache

1. Installation:

   yum install redis
   systemctl enable --now redis

2. Perl-Modul: cpan install Redis::Fast

3. SysConfig:

   Cache::Module: Redis
   Cache::Redis###Server: 127.0.0.1:6379
   Cache::Redis###DatabaseNumber: 0
   Cache::Redis###RedisFast: 1

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

mount -t tmpfs -o size=8G tmpfs /opt/otobo/var/tmp
# /etc/fstab hinzufügen:
tmpfs /opt/otobo/var/tmp tmpfs nodev,nosuid,noexec,size=8G 0 0

6. Datenbank-Tuning (MySQL/MariaDB)

Bearbeite /etc/my.cnf.d/otobo.cnf:

[mysqld]
innodb_buffer_pool_size = 12G        # 60% von 20G RAM
innodb_log_file_size    = 1G         # große Transaktionen
innodb_flush_log_at_trx_commit = 2   # Performance/OCR-Balance
max_connections         = 500       # erwartete Agenten+API
thread_cache_size       = 50        # Wiederverwendung Threads
query_cache_type        = 0         # deaktiviert (deprecated)

• 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 & Backup-Skripte

8.1 Docker-Compose-Backup

Script: /usr/local/bin/otobo_backup.sh

#!/usr/bin/env bash
set -euo pipefail
DATE=$(date +"%Y%m%d_%H%M%S")
COMPOSE_FILE=/opt/otobo-docker/compose.yml
# Stoppen für Konsistenz
docker compose -f "$COMPOSE_FILE" down
# Volumes & DB-Dump
tar -czf "/backups/volumes_$DATE.tar.gz" /var/lib/docker/volumes
mysqldump --single-transaction --quick --user=otobo --password="\$OTC_DB_PASS" otobo > "/backups/db_$DATE.sql"
# Starten
docker compose -f "$COMPOSE_FILE" up -d
echo "Backup $DATE abgeschlossen"

Cron (stündlich):

0 * * * * /usr/local/bin/otobo_backup.sh >> /var/log/otobo/backup.log 2>&1

8.2 Aufräumen alter Backups

#!/usr/bin/env bash
find /backups -type f -mtime +7 -delete

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 OTOBO/Znuny eine stabile und schnelle Plattform, die auch bei Millionen von Tickets und Artikeln reibungslos skaliert.