1 Sep
2020
1 Sep
'20
8:44 p.m.
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-per…
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/