OTOBO / Znuny – Optymalizacja wydajności

W tym szczegółowym przewodniku omawiamy wszystkie istotne poziomy dla skalowalnej i wydajnej instalacji OTOBO lub Znuny:

1. Moduły indeksowania dla kolejek ticketów
2. Wyszukiwanie pełnotekstowe i wyszukiwanie dokumentów (wewnętrzne i Elasticsearch)
3. Back-endy przechowywania artykułów (baza danych vs. system plików)
4. Archiwizacja ticketów
5. Buforowanie (Redis, Ramdisk)
6. Dostosowanie bazy danych (MySQL/MariaDB)
7. Sprzęt i infrastruktura
8. Automatyzacja (Cron, skrypty Docker-Compose)
9. Monitorowanie i alerty

1. Moduł indeksowania ticketów

1.1 RuntimeDB (domyślny)

• Moduł: Kernel::System::Ticket::IndexAccelerator::RuntimeDB
• Funkcjonowanie: Dynamiczne zapytania bezpośrednio do tabeli ticket
• Zakres stosowania: Do ~60k otwartych ticketów bez zauważalnej opóźnienia
• Miara: Czas zapytania ∝ liczba ticketów ➔ liniowy wzrost

1.2 StaticDB (wysoka skala)

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

• Funkcjonowanie: Przygotowana tabela ticket_index z kolumnami tokenów (temat, status, właściciel itp.)

• Zakres stosowania: >80k otwartych ticketów, 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 wykonywania: pomiar za pomocą polecenia time

2. Wyszukiwanie pełnotekstowe i wyszukiwanie dokumentów

2.1 Wewnętrzny indeks pełnotekstowy

• Polecenie do przebudowy:

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

• Zalecana konfiguracja SysConfig:

  Ustawienie	Wartość	Cel
  Ticket::SearchIndex::IndexArchivedTickets	0 (wyłączone)	Wykluczanie zarchiwizowanych ticketów
  Ticket::SearchIndex::Attribute.WordCountMax	1000	Indeksowanie pierwszych 1000 słów
  Ticket::SearchIndex::Filters	Domyślny	Filtrowanie wyrażeń regularnych
  Ticket::SearchIndex::StopWords###Custom	pl, en	Dodawanie własnych słów stop

• Przykład filtra (SysConfig pod filtrem):

  s#[,\&<>?"!*\|;\[\]()\+\$\^=]# #g   # Usuwanie znaków specjalnych
  s#\b\S{1,2}\b##g                       # Usuwanie słów <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ć pauzy GC
• Max ≤ 50% fizycznej pamięci RAM

2.2.2 Znaczniki 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 na tryb tylko do odczytu

2.2.3 Optymalizacje mapowania

• keyword-typ dla pól rzadko zmienianych (np. ID ticketów)
• text + analyzer dla pełnotekstowych pól

3. Back-endy przechowywania artykułów

Back-end	Miejsce przechowywania	Zastosowanie
DB	MySQL/MariaDB	< 10k załączników, pojedynczy serwer
FS	lokalny system plików / NFS / SAN	≥ 10k załączników, wieloserwerowy, wysoka wydajność IOPS

3.1 Zmiana 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 ticketów

Redukuje aktywnie indeksowane rekordy.

1. SysConfig: Ticket::ArchiveSystem = 1

2. Zadanie GenericAgent:

   • Limit: maks. 5000 ticketów na wykonanie
   • Filtrowanie: State = close I Changed < now-6mon

3. Cron (co tydzień o 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
# /etc/fstab dodaj:
tmpfs /opt/otobo/var/tmp tmpfs nodev,nosuid,noexec,size=8G 0 0

6. Dostosowanie 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   # Balans pomiędzy wydajnością i OCR
max_connections         = 500       # oczekiwane połączenia agentów i API
thread_cache_size       = 50        # ponowne wykorzystanie wątków
query_cache_type        = 0         # wyłączone (przestarzałe)

• Test wydajności: TPC-C lub sysbench dla testów obciążeniowych

7. Sprzęt i infrastruktura

• Procesor: ≥ 8 rdzeni dla równoległości
• Pamięć RAM: Wystarczająca dla puli bazy danych + JVM + buforów
• Przechowywanie: Dyski NVMe-SSD w RAID10 (≥ 10k IOPS)
• Sieć: 10 GbE między frontendem a bazą danych
• Load-balancer: HAProxy lub NGINX z testami wydajności

8. Automatyzacja i skrypty kopii zapasowych

8.1 Skrypt kopii zapasowej Docker-Compose

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

#!/usr/bin/env bash
set -euo pipefail
DATA=$(date +"%Y%m%d_%H%M%S")
PLIK_KOMPOZYCJI=/opt/otobo-docker/compose.yml
# Zatrzymaj dla spójności
docker compose -f "$PLIK_KOMPOZYCJI" down
# Volumeny i dump bazy danych
tar -czf "/backups/volumes_$DATA.tar.gz" /var/lib/docker/volumes
mysqldump --single-transaction --quick --user=otobo --password="\$OTC_DB_PASS" otobo > "/backups/db_$DATA.sql"
# Uruchom
docker compose -f "$PLIK_KOMPOZYCJI" up -d
echo "Kopia zapasowa $DATA zakończona"

Cron (co godzinę):

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

8.2 Czyścenie 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: otobo-agent metryki (czas odpowiedzi, głębokość kolejki)

• Pulpit nawigacyjny Grafana:

  • Czas opóźnienia zapytań (95. percentyl)
  • Trafienie buforu Redis vs. brak trafienia
  • Użycie puli buforowej InnoDB
  • Status shardów Elasticsearch

• Reguły alertów:

  • Wolne zapytania > 200 ms przez > 5 min
  • Znacznik dysku > 90%
  • Pauzy w stosie > 100 ms
  • Połączenia bazy danych > 80% z max_connections

Podsumowanie

Z tym kompleksowym planem optymalizacji wydajności na poziomie indeksowania, wyszukiwania, przechowywania, buforowania, dostosowania bazy danych i infrastruktury osiągniesz stabilną i szybką platformę OTOBO/Znuny, która skaluje się płynnie nawet przy milionach ticketów i artykułów.