[SOLVED] Internal server error 500 when WEB_CONCURRENCY is set >1

  • Used Zammad version: 2.7.x
  • Used Zammad installation source: (source, package, …) package
  • Operating system: Debian 9
  • Browser + version: Firefox latest

Expected behavior:

  • Raising zammads WEB_CONCURRENCY to higher values increases speed of web interface if multiple agents are active.

Bit of setup background:
Our hardware is 1 CPU 4 cores.
~50 Agents
~30 Groups with 2 Overviews each
~1000 tickets
~15 agents working on peak time
Storage mechanizm is set to Filesystem in Zammad->Admin->System->Storage

Actual behavior:

  • UI speeds up, however while working with tickets agents get Internal Server Error 500.
  • It can be clicked away and the UI is responsive without issues, however we can’t find the source of the error so far.

Where are the errors logged into? production.log did not show any error 500.
Additionally to raising WEB_CONCURRECNTY we set MAX_ and MIN_THREADS to 30 and 6 respectively.
According to our system monitoring tool the sql process uses ~10 % CPU time regularly. The puma process uses 30-50% regularly.

Suggestions on how to debug this issue are welcome.

The first thing that comes to mind is to have a look at postgres logs for psql: FATAL: remaining connection slots are reserved for non-replication superuser connections
and if you see it, increase max_connections.

1 Like


yes, that is exactly what the error log is filled with. Good hint.
How do I increase the max_connections number exactly?
And what are the limits of that number I should be aware of?


increasing it is easy enough, the file is /etc/postgresql/9.5/main/postgresql.conf but 9.5 might be some other number for you, and the setting is called max_connections.

The right number is complicated and it depends on your memory, 8GB minus the memory elasticsearch, rails and whatever else is running is what’s available for postgres. and also the other settings in postgres that affect memory because how much memory postgres will try to use is affected by max_connections, ie max_connections * “some other setting”.

It’s not a science, it’s an art, maybe guess at 3 or 4GB available for postgres, pick a number for max_connections, I think the default is 100, so maybe try 200, fill out the rest of the questions and see what pgtune comes up with.

and you hve to restart postgres after you make the changes to postgresql.conf

1 Like


This seems to have worked, no more errors so far.
Thank you very much for the info.


1 Like

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