Zammad Slow UI Despite Healthy DB and Elasticsearch

Technical assistance
1

Infos:

  • Zammad Version: 6.5.2
  • Installation Type: Package
  • OS: Ubuntu 22.04 LTS
  • Browser: Multiple (tested with Chrome)

Environment Details:

Zammad / App Server

  • 71 GB used disk space
  • 48 CPU cores
  • 126 GB of RAM
  • WEB_CONCURRENCY=12
  • ZAMMAD_PROCESS_DELAYED_JOBS_WORKERS=16
  • ZAMMAD_PROCESS_SESSIONS_JOBS_WORKERS=16
  • MAX_THREADS=8
  • MIN_THREADS=4
  • RAILS_MAX_THREADS=8
  • Redis (local)
  • Memcached (local)
  • Attachments stored on S3
  • 155+ active users working simultaneously
  • 22 email accounts connected via Microsoft 365 (Graph API)
  • 211 ticket overviews in use

PostgreSQL 14

  • max_connections = 400
  • shared_buffers = 24GB
  • temp_buffers = 32MB
  • work_mem = 64MB
  • effective_cache_size = 96GB

PgBouncer

  • pool_mode = session
  • max_client_conn = 5000
  • default_pool_size = 200
  • reserve_pool_size = 100
  • reserve_pool_timeout = 5

Elasticsearch

  • Heap size: 16GB (-Xms16g -Xmx16g)
  • http.max_content_length: 400mb

Problem / Question

We’re experiencing significant delays in Zammad—updating a ticket can take several minutes.

Elasticsearch is green, PostgreSQL shows no bottlenecks, and there are no job queues.

Has anyone encountered similar behavior?

We understand there are many views, users, and emails at once, but there should be a way to reach a reasonable balance—not perfect performance, just average responsiveness.

Any guidance would be greatly appreciated.

Thanks in advance!

2

You configured extremely heavy performance tunings with max_connections of 400 only and used pgbouncer instead. pgbouncer is not officially supported by Zammad. You might want to not use pgbouncer and use fitting max_connections. Per process you’ll need 50 connections.

We can continue with that, if vanilla configuration also is unstable / unreliable.

A side not: Zammad 6.5.2 is outdated, 6.5.3 and 6.5.4 are security advisories.