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.

Znuny Health Check & Performance Tuning

Slow load times or high server load? We optimize database queries, indexing, caching, and daemon workers for noticeably faster response times.

Book performance audit

Frequently asked questions

When should I switch Znuny from RuntimeDB to StaticDB for optimal performance?

You should consider switching from RuntimeDB to StaticDB when your Znuny installation has approximately 80,000 or more open tickets. RuntimeDB, the standard module, performs dynamic queries directly on the ticket table, leading to query times that increase linearly with the number of tickets. In contrast, StaticDB uses a precompiled ticket_index table, which includes tokenized columns for subject, status, owner, and other attributes. This approach ensures constant query times, regardless of the growing number of tickets. After switching, an initial indexing is required, and a daily cron job (e.g., at 02:30 AM) should be set up to rebuild the index. For further optimization, enable automatic partial rebuilds only for changed queues via SysConfig.

Quellen / Sources:

• Znuny Documentation – Performance Optimization
• OTOB Performance Optimization – Scaling for High Ticket Volume

Is Elasticsearch mandatory for Znuny's full-text search, and when is it recommended?

No, Elasticsearch is not mandatory for Znuny's full-text search. Znuny includes an internal full-text index that is sufficient for most installations. You can rebuild this internal index using a specific command and configure it with SysConfig settings like Ticket::SearchIndex::IndexArchivedTickets (set to 0 to exclude archived tickets) and Ticket::SearchIndex::Attribute.WordCountMax (to index the first 1000 words). Elasticsearch becomes recommended for very large data volumes, typically exceeding 10 million articles, where its advanced capabilities and scalability offer significant benefits. When using Elasticsearch, critical optimizations include setting JVM Heap Size (Min = Max, and Max ≤ 50% of physical RAM), configuring Disk Watermarks (low/high for shard allocation, flood_stage for read-only indices), and optimizing mapping types (e.g., keyword for IDs, text with analyzer for free text).

Quellen / Sources:

• Znuny Documentation – Performance Optimization
• OTOB Performance Optimization – Scaling for High Ticket Volume

How does ticket archiving improve Znuny performance, and what's the recommended setup?

Ticket archiving significantly improves Znuny performance by actively reducing the number of data records that need to be indexed and queried. This ensures that queue views and searches remain fast, even on large installations with millions of tickets. To set up ticket archiving, first enable it in SysConfig by setting Ticket::ArchiveSystem = 1. Next, configure a GenericAgent job to automate the archiving process. It's recommended to limit each run to a maximum of 5,000 tickets and apply a filter such as State = close AND Changed < now-6mon to archive older, closed tickets. Finally, schedule this GenericAgent job via a cron entry, for example, weekly on Monday at 4:00 AM, to ensure regular maintenance and sustained performance.

Quellen / Sources:

• Znuny Documentation – Performance Optimization
• Znuny Documentation — Admin Manuals

What are the best practices for choosing and switching Znuny's article storage backend (DB vs. FS)?

Choosing the right article storage backend is crucial for Znuny's performance. The DB backend (MySQL/MariaDB) is suitable for installations with fewer than 10,000 attachments and single-server setups. For larger installations, specifically those with 10,000 or more attachments, or multi-server environments requiring high IOPS, the FS backend (local FS / NFS / SAN) is recommended. When switching between DB and FS, it's essential to monitor the process by checking the /opt/znuny/var/log/article_storage.log for any errors or progress updates. Additionally, pay close attention to file permissions, ensuring that the znuny user (typically UID 1000) has the necessary read and write access to the new storage location to prevent issues with article retrieval and storage.

Quellen / Sources:

• Znuny Documentation – Performance Optimization
• OTOB Performance Optimization – Scaling for High Ticket Volume

How can caching with Redis and Ramdisk enhance Znuny's performance?

Caching mechanisms like Redis and Ramdisk can significantly enhance Znuny's performance by reducing the load on the database and speeding up access to frequently used data. For Redis Cache, the setup involves three main steps: first, install Redis on your server; second, install the necessary Perl module by running cpan install Redis::Fast; and third, configure Redis in Znuny's SysConfig. This allows Znuny to store session data, configuration, and other temporary information in a fast in-memory cache. Additionally, utilizing a Ramdisk for /opt/znuny/var/tmp can further boost performance. By mounting a portion of your RAM as a temporary file system, operations involving temporary files (which Znuny frequently uses) become much faster than writing to a traditional disk, leading to quicker overall response times and reduced I/O bottlenecks.

Quellen / Sources:

• Znuny Documentation – Performance Optimization
• OTOB Performance Optimization – Scaling for High Ticket Volume

What are the critical database tuning recommendations for MySQL/MariaDB to optimize Znuny performance?

Optimizing your MySQL/MariaDB database is a cornerstone of Znuny performance. While specific parameters depend on your server's hardware and workload, the general approach involves editing the configuration file, typically located at /etc/my.cnf.d/znuny.cnf. Key areas for tuning often include innodb_buffer_pool_size (to allocate sufficient memory for data and index caching), innodb_log_file_size (to optimize write performance), and max_connections (to handle concurrent user loads). It's crucial to benchmark your changes using tools like TPC-C or sysbench to simulate load and validate that your tuning efforts yield tangible performance improvements without introducing instability. Monitoring metrics such as InnoDB Buffer Pool usage is vital to ensure efficient memory utilization and identify potential bottlenecks.

Quellen / Sources:

• Znuny Documentation – Performance Optimization
• OTOB Performance Optimization – Scaling for High Ticket Volume