For information, we have had to revert this change. The amount to which processes and threads were raised by this and the frontend patch are non-usable: it would spawn 20 process * 200 threads (api) + 10 processes * 100 threads (frontend) = 5000 threads. This is more than mod_wsgi is willing/able to manage with resource limits put in by the system (like e.g. max 4096 files open as hard limit). This was causing lots of the threads to be unable to be spawned, resulting in many errors filling the logs. I think that instead of bumping these, we need to analyze deeper what is causing the problems with resultsdb in responding to many requests at the same time. The section on threads= in the mod-wsgi documentation (https://modwsgi.readthedocs.io/en/develop/configuration-directives/WSGIDaemonProcess.html): Do not get carried away and set this to a very large number in the belief that it will somehow magically enable you to handle many more concurrent users. Any sort of increased value would only be appropriate where your code is I/O bound. If you code is CPU bound, you are better of using at most 3 to 5 threads per process and using more processes. _______________________________________________ infrastructure mailing list -- infrastructure@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to infrastructure-leave@xxxxxxxxxxxxxxxxxxxxxxx
