On 2020-09-01 13:34, Ali Taher wrote:
That is clear. I decreased the max worker processes to 20 to be on the safe side. But what is confusing me is what about the 18 worker processes ran by Kamailio, will they overlap with postgres processes or they are the same , knowing that Kamailio role in my case is just getting routing decision by running a query on the database and send it back to the SBC. Excuse my lack of knowledge in how linux processes work.
This isn't a question of Linux processes, but rather the concurrency model of any given software system, and the manner in which it does multiple processes to do what it does. The strategies are very different.
Kamailio works on a "pre-forked worker process" model where the kernel distributes incoming packets to one or more child processes. There is no "distributor" thread/process; they all just call accept()/recvfrom() or whatever, and something falls out from the kernel's incoming packet queue for the bound socket.
This type of architecture is fairly close to 1:1 in terms of the volume of messages that can be handled at the same time, and it is deliberately architected this way, by design, because it allows relatively little to be shared among the processes. This reduces the contention among the processes over shared data structures, which maximises throughput.
If you're interested in this topic as it relates to Kamailio specifically, you may consider giving my article from several years ago a read:
http://www.evaristesys.com/blog/tuning-kamailio-for-high-throughput-and-perf...
But there are many ways to implement multi-process concurrency, all with their own trade-offs. There can also be multiple layers to multi-process concurrency, where processes in turn spawn LWPs (Light Weight Processes, aka POSIX threads). Without knowing PostgreSQL internals deeply, I can't provide deep insight into the relationship between `max_worker_processes` and the number of queries or statements which can execute concurrently. I can only say that it the relationship between Kamailio child processes or their DB connections is not at all 1:1 to the size of the worker thread process pool in PG. As far as I know, the workload is distributed in some manner among the available worker processes, whatever their number.
In short: you do not need to worry about dimensioning the PostgreSQL max_worker_processes in some way that is precisely interrelated to the number of Kamailio child processes. Treat them as logically independent of each other.
-- Alex