Zammad slowing down more and more

Infos:

  • Used Zammad version: 6.3 (also older versions)
  • Used Zammad installation type: package
  • Operating system: Debian 12 (also 11)
  • Browser + version: Firefox, Edge, Chrome, Safari (latest)

We have 60k tickets, most of them are closed. We have noticed, that over the time, zammad got slower and slower. It’s not that bad (Creating a tickets takes a few seconds) but, most things have gotten somewhat slow. Loading overviews is sometimes taking up to 30 seconds.

The server has 8 GiB RAM and is using 5.7GiB. It also uses 30% of its 4 cpu-cores (2,1GHz).

Should we delete old Tickets or is there some configfiles we can change?

I would check the Database and Elasticsearch Node.

They could sometime hug a bit of disk space. (Disk is still free space available?)

To improve your performance, you could create several Elasticsearch Nodes in a Cluster to distribute the load.

Gotta step in sorry.
Elasticsearch has nothing to do with performance issues during ticket creations. Search indexing is run in a delayed job.

Apart from too many people trying to talk to Zammad (which would be performance tuning), if the issue comes over time and is solved by a restart, then it’s most likely a miss configured database (see: Configure Database server — Zammad System Documentation documentation )

Hey, thanks for the replies. A colleague had the idea, to migrate the vm-storage from a sata-ssd-storage to an nvme-storage, which we are testing right now.

Too many people hopefully won’t be a problem, since we only have 10 agents and we haven’t enabled the login for customers.

SSD is good.

Habe you tried to set the WEB_CONCURRENCY?

Here are the performance documentation about it: Configuration via Environment Variables — Zammad System Documentation documentation

We have 60 agents at the same time on our instance with 140.000 tickets (most are closed) and no problems after adjust the parameters.
Our setup: 6 CPU cores, 16 GB RAM on SSD Storage

MrGeneration described it here too: Performance Issues with 50 - 60 concurrent users - #2 by MrGeneration

I still suspect a faulty database configuration as OP described it comes over time. Ramping up the performance tunings will worsen the situation should I be correct.

Hey there,
sorry for no further updates, shortly after changing to nvme-storage I went on a vacation and forgot about this thread.

Migrating the storage the nvme-disks was the solution.
We had no further issues after that.

1 Like

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.