Important: If you are a Zammad Support or hosted customer and experience a technical issue, please refer to: email@example.com using your zammad-hostname / or company contract.
Used Zammad version: 2.6
Used Zammad installation source: (source, package, …) source
Operating system: OpenSuSE 42.3
Browser + version: FireFox 62 64bit
Our ticket system constantly has a very high CPU load when some agents work with the system. The ticket system then works very sluggishly, ticket replies then take up to 1 minute until they are taken over in the ticket system. Also the structure of the page or the search is very slow if several agents work with the system.
The ticket system is a virtual server with 6 Gb RAM and 4 CPUs.
Elasticsearch Version 5.6.10
What is also noticeable is that when we execute tail -f /var/log/zammad/production.log a lot of actions are executed. Zammad because it handles a lot of jobs. Can’t reduce these processes then?
Core power (GHz) is more important than cores within Zammad, as some parts run single thread which may slow things down.
Are you using CTI or other integrations?
I’m lacking the capatibility to read the atop thingie… am I reading correctly that the average load is @ 1.17 (so under 50% of overall CPU performance) ?
What kind of database are you using and what storage is underneath your system? (SSD / HDD?)
On my personal suse instance I noticed that the updates take a bit longer since the last update about 4 days ago I drove. Up until now I believed that this would be the shared infrastructure of my hoster that tends to have general slow I/O from time to time.
I just checked, my overall CPU usuage in average hasn’t changed. So it may be storage related on my end.
How many overviews are you using? Overviews tend to slow down Zammad if they get too many.
Also please run the following just to please my curiosity
Please note that LDAP synch runs hourly and might cause significant CPU usuage.
If possible, you should consider changing to SSD storage (at least for your database) as this should improve the performance.
Also, if not already done, you should consider storing your attachments on filesystem and not database, this also brings performance improvement.
The return of the above command of 0 is very good.