[SR-Users] worker processes

[Alex Balashov]

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-performance/

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

-- 
Alex Balashov | Principal | Evariste Systems LLC

Tel: +1-706-510-6800 / +1-800-250-5920 (toll-free)
Web: http://www.evaristesys.com/, http://www.csrpswitch.com/