OTOBO / Znuny – Optymalizacja Wydajności

W tym obszernym przewodniku omawiamy wszystkie istotne poziomy dla skalowalnej i wydajnej instalacji OTOBO lub Znuny:

1. Moduły indeksowania dla kolejek zgłoszeń
2. Wyszukiwanie pełnotekstowe i dokumentów (wewnętrzne i Elasticsearch)
3. Backendy przechowywania artykułów (DB vs. FS)
4. Archiwizacja zgłoszeń
5. Buforowanie (Redis, Ramdisk)
6. Strojenie bazy danych (MySQL/MariaDB)
7. Sprzęt i infrastruktura
8. Automatyzacja (Cron, skrypty Docker-Compose)
9. Monitorowanie i alerty

1. Moduł Indeksowania Zgłoszeń

1.1 RuntimeDB (Domyślny)

• Moduł: Kernel::System::Ticket::IndexAccelerator::RuntimeDB
• Działanie: Dynamiczne zapytania bezpośrednio do tabeli ticket
• Zakres użycia: Do ok. 60 tys. otwartych zgłoszeń bez zauważalnych opóźnień
• Metryka: Czas zapytania ∝ Liczba zgłoszeń ➔ liniowy wzrost

1.2 StaticDB (Duża Skala)

• Moduł: Kernel::System::Ticket::IndexAccelerator::StaticDB

• Działanie: Skompilowana z wyprzedzeniem tabela ticket_index z kolumnami tokenów (temat, status, właściciel i wiele innych)

• Zakres użycia: >80 tys. otwartych zgłoszeń, stałe czasy zapytań

• Początkowe indeksowanie:

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

• Przykład Cron: Codzienny rebuild o 02:30

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

• Wskazówki dotyczące optymalizacji:

  • Automatyczne częściowe rebuildy tylko dla zmienionych kolejek (opcja SysConfig)
  • Monitorowanie czasu wykonania: mierzenie za pomocą polecenia time

2. Wyszukiwanie Pełnotekstowe i Dokumentów

2.1 Wewnętrzny Indeks Pełnotekstowy

• Polecenie rebuild:

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

• Zalecane SysConfig:

  Ustawienie	Wartość	Cel
  Ticket::SearchIndex::IndexArchivedTickets	0 (wyłączone)	Wyklucz zindeksowane archiwalne zgłoszenia
  Ticket::SearchIndex::Attribute.WordCountMax	1000	Indeksuj pierwsze 1000 słów
  Ticket::SearchIndex::Filters	Standard	Filtry Regex dla znaków specjalnych
  Ticket::SearchIndex::StopWords###Custom	de, en	Dodaj własne słowa pomijane

• Przykład filtra (SysConfig w sekcji Filters):

  s#[,\&<>?"!*\|;\[\]()\+\$\^=]# #g   # Usuń znaki specjalne
  s#\b\S{1,2}\b##g                       # Usuń słowa <3 znaków

2.2 Elasticsearch (opcjonalnie)

Dla dużych ilości danych (>10M artykułów) zalecany jest Elasticsearch.

2.2.1 Rozmiar sterty JVM

# jvm.options
-Xms4g
-Xmx4g

• Ustaw Min = Max, aby zminimalizować przerwy GC
• Max ≤ 50% pamięci RAM

2.2.2 Watermarki dysku

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

• low/high dla alokacji shardów
• flood_stage ustawia indeksy jako tylko do odczytu

2.2.3 Optymalizacje mapowania

• Typ keyword dla rzadko zmienianych pól (np. ID zgłoszeń)
• text + analyzer dla tekstu swobodnego

3. Backendy Przechowywania Artykułów

Backend	Lokalizacja przechowywania	Użycie
DB	MySQL/MariaDB	< 10 tys. załączników, serwer pojedynczy
FS	lokalny FS / NFS / SAN	≥ 10 tys. załączników, serwer wielokrotny, wysokie IOPS

3.1 Przełączanie DB ↔ FS

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

• Sprawdź /opt/otobo/var/log/article_storage.log
• Zwróć uwagę na uprawnienia: użytkownik otobo (UID 1000)

4. Archiwizacja Zgłoszeń

Zmniejsza liczbę aktywnie indeksowanych rekordów.

1. SysConfig: Ticket::ArchiveSystem = 1

2. Skonfiguruj Zadanie GenericAgent:

   • Limit: maksymalnie 5000 zgłoszeń na przebieg
   • Filtr: State = close ORAZ Changed < now-6mon

3. Cron (cotygodniowo, poniedziałek 4:00):

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

5. Buforowanie

5.1 Bufor Redis

1. Instalacja:

   yum install redis
   systemctl enable --now redis

2. Moduł Perl: 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 dla /opt/otobo/var/tmp

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

6. Strojenie Bazy Danych (MySQL/MariaDB)

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

[mysqld]
innodb_buffer_pool_size = 12G        # 60% z 20G RAM
innodb_log_file_size    = 1G         # duże transakcje
innodb_flush_log_at_trx_commit = 2   # równowaga między wydajnością a trwałością (ACID)
max_connections         = 500       # oczekiwani agenci + API
thread_cache_size       = 50        # ponowne wykorzystanie wątków
query_cache_type        = 0         # wyłączone (przestarzałe)

• Benchmark: TPC-C lub sysbench do testów obciążeniowych

7. Sprzęt i Infrastruktura

• CPU: ≥ 8 rdzeni dla równoległości
• RAM: Wystarczająco dla puli DB + JVM + buforów
• Storage: Dyski NVMe SSD w RAID10 (≥ 10 tys. IOPS)
• Sieć: 10 GbE między frontendem a bazą danych
• Load-Balancer: HAProxy lub NGINX z testami poprawności działania (Health-Checks)

8. Automatyzacja i Skrypty Kopii Zapasowych

8.1 Docker-Compose Backup

Skrypt: /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
# Zatrzymaj dla spójności
docker compose -f "$COMPOSE_FILE" down
# Wolumeny i zrzut bazy danych
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"
# Uruchom ponownie
docker compose -f "$COMPOSE_FILE" up -d
echo "Backup $DATE zakończony"

Cron (co godzinę):

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

8.2 Czyszczenie starych kopii zapasowych

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

Cron: codziennie o 1:00

9. Monitorowanie i Alerty

• Eksporter Prometheus: Metryki otobo-agent (ResponseTime, QueueDepth)

• Dashboard Grafana:

  • Opóźnienie zapytań (95. percentyl)
  • Trafienia vs. Pomyłki w buforze Redis
  • Użycie bufora InnoDB
  • Status shardów Elasticsearch

• Reguły alertów:

  • Powolne zapytania > 200 ms przez > 5 min
  • Watermark dysku > 90%
  • Przerwy sterty > 100 ms
  • Połączenia DB > 80% max_connections

Wnioski

Dzięki temu kompleksowemu planowi optymalizacji wydajności na poziomie indeksowania, wyszukiwania, przechowywania, buforowania, bazy danych i infrastruktury, osiągniesz stabilną i szybką platformę w OTOBO/Znuny, która będzie płynnie skalować się nawet przy milionach zgłoszeń i artykułów.