Scheduler tasks limited to one CPU thread

Hello,

I have a question regarding the performance of the task scheduler.
I couldn’t find any topic about CPU multithreading.

Info:

  • Used Zammad version: 5.1.1
  • Used Zammad installation type: package
  • Operating system: CentOS 7
  • Browser + version: Firefox v102

Expected behavior:

Have a fast execution of tasks modifying more than 500 tickets in the scheduler (at least, use a larger CPU percentage of the machine)

Actual behavior:

A task that modifies about 1000 tickets (700/1100/2000+ for testing) in the scheduler runs in about 5 minutes, and ticket changes are visible after about 30 minutes.
The “top” utility indicates 100% utilization (single thread) for the zammad user’s ruby ​​command (script?) when the task is being performed (drops to 0% when finished).
Total CPU usage does not exceed 16% (8 Threads).

Steps to reproduce the behavior:

Create a task in the scheduler which aims to modify a “select” field on a large selection of tickets (1000+).
Example: all tickets in the “open” state in group A are moved to group B with the state “new”.
Have a 4+ thread cpu machine and check the performance monitor (does not exceed 1 thread).


To simply ask: Do you know if it is possible to enable multithreading on zammad’s ruby ​​scripts?

I have also observed that tasks modifying more than 2000 tickets show the correct number of modified elements, but only really modify 2000 (tickets are not modified from 2001+).
A ticket on Github is already open, so I won’t talk about it here.

Thanks !
Regards

Spotted !

Ok mates, I think I found my happiness.
I saw that the doc was updated :
https://docs.zammad.org/en/latest/appendix/configure-env-vars.html#performance-tuning

There is a new variable : ZAMMAD_PROCESS_DELAYED_JOBS_WORKERS (comes with Zammad 5.2.1)
I updated my zammad installation from 5.1.1 to 5.2.1 and put “zammad config:set ZAMMAD_PROCESS_DELAYED_JOBS_WORKERS=4” then a restart.

Et voilà : now, a big scheduled job with a 1950 ticket modification run on approx. 8 minutes (before, was 30~40 minutes).
On “top”, we can see the traditionnal zammad’s ruby command with ~90% cpu’s thread, and 4 more ruby commands who take ~80~90%.
The total cpu’s use is about 50~60% (I didn’t want to put more, in case)

Note : the ZAMMAD_SESSION_JOBS_CONCURRENT variable was already set to 4 before this change, but didn’t help me.

Hope this can help !

1 Like