Znuny – Optimización del rendimiento

Znuny – Optimización del rendimiento

En esta guía detallada, cubrimos todos los niveles relevantes para una instalación de Znuny escalable y de alto rendimiento:

1. Módulos de índice para colas de tickets
2. Búsqueda de texto completo y de documentos (interna y Elasticsearch)
3. Backends de almacenamiento de artículos (DB vs. FS)
4. Archivado de tickets
5. Caché (Redis, Ramdisk)
6. Ajuste de base de datos (MySQL/MariaDB)
7. Hardware e infraestructura
8. Automatización (Cron, scripts de Docker-Compose)
9. Monitorización y alertas

1. Módulo de índice de tickets

1.1 RuntimeDB (Estándar)

• Módulo: Kernel::System::Ticket::IndexAccelerator::RuntimeDB
• Funcionamiento: Consultas dinámicas directamente sobre la tabla ticket
• Ámbito de aplicación: Hasta ~60k tickets abiertos sin latencia perceptible
• Métrica: Tiempo de consulta ∝ número de tickets ➔ aumento lineal

1.2 StaticDB (High-Scale)

• Módulo: Kernel::System::Ticket::IndexAccelerator::StaticDB
• Funcionamiento: Tabla ticket_index precompilada con columnas de tokens (asunto, estado, propietario, etc.)
• Ámbito de aplicación: >80k tickets abiertos, tiempos de consulta constantes
• Indexación inicial: Kernel::System::Ticket::IndexAccelerator::RuntimeDB
• Ejemplo de Cron: Reconstrucción diaria a las 02:30 ticket
• Consejos de optimización:
  • Reconstrucciones parciales automáticas solo para colas modificadas (opción de SysConfig)
  • Monitorización del tiempo de ejecución: medir mediante el comando time

2. Búsqueda de texto completo y búsqueda de documentos

2.1 Índice de texto completo interno

• Comando para reconstrucción: Kernel::System::Ticket::IndexAccelerator::StaticDB
• SysConfig recomendada:

  Ajuste	Valor	Propósito
  Ticket::SearchIndex::IndexArchivedTickets	0 (off)	Excluir tickets archivados
  Ticket::SearchIndex::Attribute.WordCountMax	1000	Indexar las primeras 1000 palabras
  Ticket::SearchIndex::Filters	Estándar	Filtro Regex para caracteres especiales
  Ticket::SearchIndex::StopWords###Custom	de, en	Añadir palabras vacías propias

• Ejemplo de filtro (SysConfig en Filters): ticket_index

2.2 Elasticsearch (opcional)

Para grandes volúmenes de datos (>10M de artículos) se recomienda Elasticsearch.

2.2.1 Tamaño del Heap de JVM

time

• Establecer Min = Max para minimizar las pausas de GC
• Max ≤ 50% de la RAM física

2.2.2 Marcas de agua de disco (Disk Watermarks)

keyword

• low/high para la asignación de shards
• flood_stage establece los índices como de solo lectura

2.2.3 Optimizaciones de mapeo

• Tipo keyword para campos que cambian poco (p. ej., IDs de ticket)
• text + analyzer para texto libre

3. Backends de almacenamiento de artículos

Backend	Ubicación de almacenamiento	Uso
DB	MySQL/MariaDB	< 10k adjuntos, servidor único
FS	FS local / NFS / SAN	≥ 10k adjuntos, multi-servidor, alto IOPS

3.1 Cambio DB ↔ FS

text

• Comprobar /opt/znuny/var/log/article_storage.log
• Prestar atención a los permisos: usuario znuny (UID 1000)

4. Archivado de tickets

Reduce activamente los registros indexados.

1. SysConfig: Ticket::ArchiveSystem = 1
2. Configurar trabajo de GenericAgent:
   • Límite: máx. 5000 tickets por ejecución
   • Filtro: State = close Y Changed < now-6mon
3. Cron (semanal, lunes 4:00): analyzer

5. Caché

5.1 Caché Redis

1. Instalación: /opt/znuny/var/log/article_storage.log
2. Módulo Perl: cpan install Redis::Fast
3. SysConfig: znuny

5.2 Ramdisk para /opt/znuny/var/tmp

Ticket::ArchiveSystem = 1

6. Ajuste de base de datos (MySQL/MariaDB)

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

• Benchmark: TPC-C o sysbench para pruebas de carga

7. Hardware e infraestructura

• CPU: ≥ 8 núcleos para paralelismo
• RAM: Suficiente para pool de DB + JVM + cachés
• Almacenamiento: SSDs NVMe en RAID10 (≥ 10k IOPS)
• Red: 10 GbE entre Frontend y DB
• Balanceador de carga: HAProxy o NGINX con comprobaciones de estado (health-checks)

8. Automatización y scripts de monitorización

8.1 Monitorización del rendimiento

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

8.2 Limpieza de logs antiguos

/opt/znuny/var/tmp Cron: diario a la 1:00

9. Monitorización y alertas

• Prometheus Exporter: Métricas de znuny-agent (ResponseTime, QueueDepth)
• Dashboard de Grafana:
  • Latencia de consulta (percentil 95)
  • Aciertos vs. fallos de caché Redis
  • Uso del InnoDB Buffer Pool
  • Estado de los shards de Elasticsearch
• Reglas de alerta:
  • Consultas lentas > 200 ms durante > 5 min
  • Marca de agua de disco > 90%
  • Pausas de Heap > 100 ms
  • Conexiones a DB > 80% de max_connections

Conclusión

Con este plan integral de optimización del rendimiento a nivel de índice, búsqueda, almacenamiento, caché, base de datos e infraestructura, logrará una plataforma Znuny estable y rápida que escala sin problemas incluso con millones de tickets y artículos.