Znuny – Performance Optimization

In this in-depth guide, we cover all relevant layers for a scalable and high-performance Znuny installation:

1. Index modules for ticket queues
2. Full-text and document search (internal & Elasticsearch)
3. Article storage backends (DB vs. FS)
4. Ticket archiving
5. Caching (Redis, Ramdisk)
6. Database tuning (MySQL/MariaDB)
7. Hardware & infrastructure
8. Automation (Cron, Docker-Compose scripts)
9. Monitoring & alerts

1. Ticket Index Module

1.1 RuntimeDB (Standard)

• Module: Kernel::System::Ticket::IndexAccelerator::RuntimeDB
• Functionality: Dynamic queries directly on the ticket table
• Use case: Up to ~60k open tickets without noticeable latency
• Metric: Query-Time ∝ Number of tickets ➔ linear increase

1.2 StaticDB (High-Scale)

• Module: Kernel::System::Ticket::IndexAccelerator::StaticDB
• Functionality: Precompiled ticket_index table with token columns (subject, status, owner, etc.)
• Use case: >80k open tickets, constant query times
• Initial indexing: Kernel::System::Ticket::IndexAccelerator::RuntimeDB
• Cron example: Daily rebuild at 02:30 AM ticket
• Optimization tips:
  • Automatic partial rebuilds only for changed queues (SysConfig option)
  • Monitoring runtime: measure via time command

2. Full-Text Search & Document Search

2.1 Internal Full-Text Index

• Command for rebuild: Kernel::System::Ticket::IndexAccelerator::StaticDB
• Recommended SysConfig:

  Setting	Value	Purpose
  Ticket::SearchIndex::IndexArchivedTickets	0 (off)	Exclude archived tickets
  Ticket::SearchIndex::Attribute.WordCountMax	1000	Index first 1000 words
  Ticket::SearchIndex::Filters	Standard	Regex filter for special chars
  Ticket::SearchIndex::StopWords###Custom	de, en	Add custom stopwords

• Example filter (SysConfig under Filters): ticket_index

2.2 Elasticsearch (optional)

For large data volumes (>10M articles), Elasticsearch is recommended.

2.2.1 JVM Heap Size

time

• Set Min = Max to minimize GC pauses
• Max ≤ 50% of physical RAM

2.2.2 Disk Watermarks

keyword

• low/high for shard allocation
• flood_stage sets indices to read-only

2.2.3 Mapping Optimizations

• keyword type for rarely changed fields (e.g., ticket IDs)
• text + analyzer for free text

3. Article Storage Backends

Backend	Storage Location	Use Case
DB	MySQL/MariaDB	< 10k attachments, single-server
FS	local FS / NFS / SAN	≥ 10k attachments, multi-server, high IOPS

3.1 Switching DB ↔ FS

text

• Check /opt/znuny/var/log/article_storage.log
• Pay attention to permissions: user znuny (UID 1000)

4. Ticket Archiving

Actively reduces indexed data records.

1. SysConfig: Ticket::ArchiveSystem = 1
2. Set up GenericAgent job:
   • Limit: max. 5000 tickets per run
   • Filter: State = close AND Changed < now-6mon
3. Cron (weekly Mon 4:00 AM): analyzer

5. Caching

5.1 Redis Cache

1. Installation: /opt/znuny/var/log/article_storage.log
2. Perl module: cpan install Redis::Fast
3. SysConfig: znuny

5.2 Ramdisk for /opt/znuny/var/tmp

Ticket::ArchiveSystem = 1

6. Database Tuning (MySQL/MariaDB)

Edit /etc/my.cnf.d/znuny.cnf: State = close

• Benchmark: TPC-C or sysbench for load testing

7. Hardware & Infrastructure

• CPU: ≥ 8 cores for parallelism
• RAM: Sufficient for DB pool + JVM + caches
• Storage: NVMe-SSDs in RAID10 (≥ 10k IOPS)
• Network: 10 GbE between frontend & DB
• Load-Balancer: HAProxy or NGINX with health checks

8. Automation & Monitoring Scripts

8.1 Performance Monitoring

Script: /usr/local/bin/znuny_monitor.sh Changed < now-6mon Cron (hourly): cpan install Redis::Fast

8.2 Cleaning up old logs

/opt/znuny/var/tmp Cron: daily 1:00 AM

9. Monitoring & Alerts

• Prometheus Exporter: znuny-agent metrics (ResponseTime, QueueDepth)
• Grafana Dashboard:
  • Query latency (95th percentile)
  • Redis cache hits vs. misses
  • InnoDB Buffer Pool usage
  • Elasticsearch shard status
• Alert Rules:
  • Slow queries > 200 ms for > 5 min
  • Disk watermark > 90%
  • Heap pauses > 100 ms
  • DB connections > 80% of max_connections

Conclusion

With this comprehensive performance tuning plan covering index, search, storage, cache, database, and infrastructure layers, you will achieve a stable and fast platform in Znuny that scales smoothly even with millions of tickets and articles.

Frequently asked questions

When should I switch Znuny from RuntimeDB to StaticDB?

Use StaticDB when you have roughly 80k or more open tickets and need constant query times instead of RuntimeDB's linear growth.

Is Elasticsearch required for Znuny full-text search?

No. Znuny has an internal full-text index; Elasticsearch is optional for very large volumes (for example, more than about 10 million articles).

How does ticket archiving help Znuny performance?

Archiving reduces the number of actively indexed tickets so queue views and searches stay faster on large installations.