Constantly Very high CPU load when multiple agents are working on the system

[dak91]

Infos:

Important:
If you are a Zammad Support or hosted customer and experience a technical issue, please refer to: support@zammad.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

Expected behavior:

Actual behavior:

• 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?

What could be the reason for the high CPU load?

[dvnkln]

Hey @dak91,

i can’t really tell you why there is such a high load. I know zammad runs a lot of schedulers in the background which really have to handle a lot.

But most of the time a slow performance is because of the application server limitation.

Have a look at the other topics who handled this problem:

Performance optimization

Infos: Used Zammad version: 2.4 Used Zammad installation source: (source, package, …) deb Operating system: Ubuntu 16.04 Browser + version: latest versions of: Chrome, Firefox, Edge (17) Expected behavior: Opening a ticket should take less than 3 seconds. Actual behavior: We use the latest version of zammad (2.4). Actually we are 15 agents with about 800 tickets. When we open a ticket we have to wait about 3 seconds to see it. The same if we want to edit an user or organisation. Our server …

cheers

[MrGeneration]

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

zammad run rails r 'p Delayed::Job.count'

[dak91]

The Result of the command is 0

[dak91]

We just activated LDAP integration. We run postgres as database and only HDDs are installed in the server.

[MrGeneration]

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.