Hello Sarju,
if you are having 12 CPU cores, you should utilize them. Use system observation tools like top etc.. to see how many workers are actually busy. You can also observe UDP queues, see worker details with kamcmd/kamctl. Kamailio worker can be configured for protocols and also modules for HTTP etc..
Cheers,
Henning
From: Sarju Garg sarju@goldilocks-tech.com Sent: Sonntag, 1. März 2026 01:38 To: Henning Westerholt hw@gilawa.com; sr-users@lists.kamailio.org Cc: Chandrabhan Kumar chandrabhan.kumar@goldilocks-tech.com Subject: Re: [sr-dev] Re: SO_REUSEPORT
Thanks. It worked..
I just wanted to know one thing
We have an environment set up with 2 server each having 12 cores and 64 GB RAM.
On first server we have two stubs: 1) sipp stub for sending SIP load and 2) nginx with lua script to receive the HTTP requests and send responses
On second server, we have our applicaiton on Kamalio using native script. The script is a simple application where when INVITE is received, it reject the call (4xx) and hit a HTTP trigger in async mode. Transaction module is used to keep track of it.
I want to set the connection and worker count in the program. I am first running load for 5000 TPS.
My understanding is that since the SIP load is coming from same tuple, there will be no multiple queues (concept of port reuse) . So having multiple connection may increase contention. What should be the ideal size. I think 4 should be good enough? How can I check in logs how many instances are needed.
The same for worker thread, the nginx is not doing much time and just need to log the request. So 4 async_workers should be enough too.
We are currently testind and experiencing connection timeout between kamailo and nginx.
Current connection and async workers are 8 and http connection timeout is 2000 ms.
Regards
Sarju
From: Henning Westerholt <hw@gilawa.commailto:hw@gilawa.com> Date: Friday, 27 February 2026 at 4:50 PM To: "sr-users@lists.kamailio.orgmailto:sr-users@lists.kamailio.org" <sr-users@lists.kamailio.orgmailto:sr-users@lists.kamailio.org> Cc: Sarju Garg <sarju@goldilocks-tech.commailto:sarju@goldilocks-tech.com>, Chandrabhan Kumar <chandrabhan.kumar@goldilocks-tech.commailto:chandrabhan.kumar@goldilocks-tech.com> Subject: RE: [sr-dev] Re: SO_REUSEPORT
Hello,
your memory cfg is wrong, you need to reverse it.
Use: -m 2048 -M 32
For example. Note the 128MB private memory is a lot, usually this is not needed. Shared memory could be more, depending on your system and load requirements.
Cheers,
Henning
From: Chandrabhan Kumar <chandrabhan.kumar@goldilocks-tech.commailto:chandrabhan.kumar@goldilocks-tech.com> Sent: Freitag, 27. Februar 2026 12:17 To: Henning Westerholt <hw@gilawa.commailto:hw@gilawa.com>; sr-users@lists.kamailio.orgmailto:sr-users@lists.kamailio.org Cc: Sarju Garg <sarju@goldilocks-tech.commailto:sarju@goldilocks-tech.com> Subject: Re: [sr-dev] Re: SO_REUSEPORT
Hi Henning, Thank you for your quick response. As requested, please find below the relevant details. The corresponding logs are attached for your reference. We tested the following shared and private memory configuration: /usr/local/sbin/kamailio -M 2048 -m 128 -f /usr/local/etc/kamailio/kamailio_obd_missedcall.cfg -DD -E & However, we are still encountering the same error (please see the attached logs). Could you please review and advise on the next steps? If any additional information is required from our side, please let me know. Regards Chandra Bhan Kumar ________________________________ From: Henning Westerholt <hw@gilawa.commailto:hw@gilawa.com> Sent: Friday, February 27, 2026 2:49 PM To: sr-users@lists.kamailio.orgmailto:sr-users@lists.kamailio.org <sr-users@lists.kamailio.orgmailto:sr-users@lists.kamailio.org> Cc: Chandrabhan Kumar <chandrabhan.kumar@goldilocks-tech.commailto:chandrabhan.kumar@goldilocks-tech.com>; Sarju Garg <sarju@goldilocks-tech.commailto:sarju@goldilocks-tech.com> Subject: RE: [sr-dev] Re: SO_REUSEPORT
(switching to sr-users list)
Hello,
did you increase the private and shared memory pool settings? The default values are not suitable for larger tests and production environments.
Cheers,
Henning
--
Kamailio services – https://gilawa.comhttps://gilawa.com/
From: Sarju Garg <sarju@goldilocks-tech.commailto:sarju@goldilocks-tech.com> Sent: Freitag, 27. Februar 2026 02:18 To: Henning Westerholt <hw@gilawa.commailto:hw@gilawa.com>; Kamailio (SER) - Development Mailing List <sr-dev@lists.kamailio.orgmailto:sr-dev@lists.kamailio.org> Cc: camille.oudot@orange.commailto:camille.oudot@orange.com; Chandrabhan Kumar <chandrabhan.kumar@goldilocks-tech.commailto:chandrabhan.kumar@goldilocks-tech.com>; Sergey Safarov <s.safarov@gmail.commailto:s.safarov@gmail.com> Subject: Re: [sr-dev] Re: SO_REUSEPORT
Hi Henning, we've set up our servers and are currently seeing about 2000 CPS.
At 5000 CPS, Kamailio shuts down with memory logging errors.
We have an environment setup with 2 server each having 12 core and 64 GB RAM. One acting as sipp stub for generating load and second as simple application where when INVITE is received, it reject the call (4xx) and hit a HTTP trigger in async mode. Transaction module is used to keep track of it.
Do we have any ready reference guide for troubleshooting or any help how to go about fixing this point.
My understanding is it Kamalio setup should be able to handle 20k CPS for such simple application. Not sure replacing HTTP trigger with Kamalio or UDP hit may add more CPS handling capacity.
Regards
Sarju
From: Henning Westerholt <hw@gilawa.commailto:hw@gilawa.com> Date: Friday, 20 February 2026 at 12:11 PM To: "Kamailio (SER) - Development Mailing List" <sr-dev@lists.kamailio.orgmailto:sr-dev@lists.kamailio.org> Cc: "camille.oudot@orange.commailto:camille.oudot@orange.com" <camille.oudot@orange.commailto:camille.oudot@orange.com>, Sarju Garg <sarju@goldilocks-tech.commailto:sarju@goldilocks-tech.com>, Chandrabhan Kumar <chandrabhan.kumar@goldilocks-tech.commailto:chandrabhan.kumar@goldilocks-tech.com>, Sergey Safarov <s.safarov@gmail.commailto:s.safarov@gmail.com> Subject: RE: [sr-dev] Re: SO_REUSEPORT
Hello,
usually, one would be interesting in measuring CPS/CAPS throughput or concurrent calls. TPS is not such a common metric for a VoIP system.
But anyhow, its is not possible from the outside to guess if 20k TPS would be realistic in your setup. You might even run into limitation from the testing side with sipp. As said, usually you are getting issues with IO dependencies, e.g. databases or similar.
A realistic setup would usually not use only one server for this load, as you want to have a high-available setup probably.
As said, do some load tests on your side and see what you are getting. Then start analysing and eventual tuning, repeat the test and so on.
Cheers,
Henning
--
Kamailio services – https://gilawa.comhttps://gilawa.com/
From: Sarju Garg <sarju@goldilocks-tech.commailto:sarju@goldilocks-tech.com> Sent: Freitag, 20. Februar 2026 03:53 To: Henning Westerholt <hw@gilawa.commailto:hw@gilawa.com>; Kamailio (SER) - Development Mailing List <sr-dev@lists.kamailio.orgmailto:sr-dev@lists.kamailio.org> Cc: camille.oudot@orange.commailto:camille.oudot@orange.com; Chandrabhan Kumar <chandrabhan.kumar@goldilocks-tech.commailto:chandrabhan.kumar@goldilocks-tech.com>; Sergey Safarov <s.safarov@gmail.commailto:s.safarov@gmail.com> Subject: Re: [sr-dev] Re: SO_REUSEPORT
Hi Henning,
We have an environment setup with 2 server each having 12 core and 64 GB RAM. One acting as sipp stub for generating load and second as simple application where when INVITE is received, it reject the call and hit a HTTP trigger.
We expect around 20000 TPS on this setup. Is this realistic expectation.?
Regards,
Sarju
From: Henning Westerholt <hw@gilawa.commailto:hw@gilawa.com> Date: Thursday, 19 February 2026 at 5:18 PM To: "Kamailio (SER) - Development Mailing List" <sr-dev@lists.kamailio.orgmailto:sr-dev@lists.kamailio.org> Cc: Sarju Garg <sarju@goldilocks-tech.commailto:sarju@goldilocks-tech.com>, "camille.oudot@orange.commailto:camille.oudot@orange.com" <camille.oudot@orange.commailto:camille.oudot@orange.com>, Chandrabhan Kumar <chandrabhan.kumar@goldilocks-tech.commailto:chandrabhan.kumar@goldilocks-tech.com>, Sergey Safarov <s.safarov@gmail.commailto:s.safarov@gmail.com> Subject: RE: [sr-dev] Re: SO_REUSEPORT
Hello,
I think Kamailio is using for the UDP server the SO_SEADDR flag, which is somehow similar as the SO_REUSEPORT.
Kamailio is used in installation up to millions of customer devices. So, in many cases, the scaling challenges you are having are not related to Kamailio but to other infrastructure, e.g. a database or similar.
I would suggest you setup a test environment for the performance requirements you are having and then doing some actual benchmarks.
Cheers,
Henning
From: Sarju Garg <sarju@goldilocks-tech.commailto:sarju@goldilocks-tech.com> Sent: Donnerstag, 19. Februar 2026 11:09 To: Sergey Safarov <s.safarov@gmail.commailto:s.safarov@gmail.com> Cc: Kamailio (SER) - Development Mailing List <sr-dev@lists.kamailio.orgmailto:sr-dev@lists.kamailio.org>; camille.oudot@orange.commailto:camille.oudot@orange.com; Chandrabhan Kumar <chandrabhan.kumar@goldilocks-tech.commailto:chandrabhan.kumar@goldilocks-tech.com>; Henning Westerholt <hw@gilawa.commailto:hw@gilawa.com> Subject: Re: [sr-dev] Re: SO_REUSEPORT
HI Sergey, Thanks.
It supports connecting multiple child processes to a single UDP queue, but not sure if it does port reuse at UDP. There is a parameter for tcp_reuse_port.
I understand if the tuple (src ip/port and Dest ip/port) is same, then there will be multiple consumers (connection parameter to create worker thread) . So multiple process will be waiting on single queue
If I refer example in cook book ,
children=4
listen=udp:127.0.0.1:5080
listen=udp:127.0.0.1:5070
listen=udp:127.0.0.1:5060
4 children each would be created for 3 different ports, but in my case, it would be
children=4
listen=udp:127.0.0.1:5080
As my IP / port is only one. However, I want 3 different queues to be created.
As per the internet
* SO_REUSEPORT: This socket option allows multiple threads or processes to bind to the same UDP port, each with its own socket and receive queue, which helps avoid contention on a single receive buffer lock in multi-core systems.
Now since I have 3 different sources, I want to create 3 UDP queues with each having 4 consumers…
I hope I can explain my problem, and hence using the SO_REUSEPORT option in UDP
Regards
Sarju
But if src ip/port is different, like 3 src/ip sending to same dest ip/port,then 3 UDP queue is created and then multiple consumer will listen on 3 different queue.
From: Sergey Safarov <s.safarov@gmail.commailto:s.safarov@gmail.com> Date: Thursday, 19 February 2026 at 12:09 PM To: Sarju Garg <sarju@goldilocks-tech.commailto:sarju@goldilocks-tech.com> Cc: "Kamailio (SER) - Development Mailing List" <sr-dev@lists.kamailio.orgmailto:sr-dev@lists.kamailio.org>, "camille.oudot@orange.commailto:camille.oudot@orange.com" <camille.oudot@orange.commailto:camille.oudot@orange.com>, Chandrabhan Kumar <chandrabhan.kumar@goldilocks-tech.commailto:chandrabhan.kumar@goldilocks-tech.com>, Henning Westerholt <hw@gilawa.commailto:hw@gilawa.com> Subject: Re: [sr-dev] Re: SO_REUSEPORT
Kamailio supports port reuse.
You just need to enable this feature in the config file and then start several Kamailio copies. For example using different systemd units.
If I am not wrong, Kamailio supports distributing load to different processes forks on different cores. This is a present out of box and you do not need to do anything more.
Just need to create additional UDP childrens.
Sergey
On Thu, Feb 19, 2026 at 1:23 AM Sarju Garg <sarju@goldilocks-tech.commailto:sarju@goldilocks-tech.com> wrote:
Hi,
I am exploring REUSE_PORT Option for UDP.
I am getting high TPS on single UDP port say 5060.
Our customer will send the complete load from one IP and one port only. And from my side I have one IP and one port. As per my understanding in that case tuple antropy cannot be achieved so was thinking if REUSE_PORT. Can be done to have parallel queue and as per Linux document, the multiple queue on same port is created.
My TPS requirement is about 20000 and try to see if how to architect the same.
Regards
Sarju
From: Sergey Safarov <s.safarov@gmail.commailto:s.safarov@gmail.com> Date: Wednesday, 18 February 2026 at 1:44 PM To: "Kamailio (SER) - Development Mailing List" <sr-dev@lists.kamailio.orgmailto:sr-dev@lists.kamailio.org> Cc: Sarju Garg <sarju@goldilocks-tech.commailto:sarju@goldilocks-tech.com>, "camille.oudot@orange.commailto:camille.oudot@orange.com" <camille.oudot@orange.commailto:camille.oudot@orange.com>, Chandrabhan Kumar <chandrabhan.kumar@goldilocks-tech.commailto:chandrabhan.kumar@goldilocks-tech.com>, Henning Westerholt <hw@gilawa.commailto:hw@gilawa.com> Subject: Re: [sr-dev] Re: SO_REUSEPORT
for UTP transport all message to the same IP:PORT address use the same port when send via same socket.
On Wed, Feb 18, 2026 at 9:31 AM Henning Westerholt via sr-dev <sr-dev@lists.kamailio.orgmailto:sr-dev@lists.kamailio.org> wrote:
Hello,
please describe what you are wanting to achieve. When we are talking about re-using ports in the SIP Kamailio context, usually its about TCP connections. This is supported from Kamailio when activated in the core.
Cheers,
Henning
-- Kamailio services – https://gilawa.com
-----Original Message----- From: Sarju Garg <sarju@goldilocks-tech.commailto:sarju@goldilocks-tech.com> Sent: Mittwoch, 18. Februar 2026 03:57 To: Federico Cabiddu <federico.cabiddu@gmail.commailto:federico.cabiddu@gmail.com> Cc: Henning Westerholt <hw@gilawa.commailto:hw@gilawa.com>; Kamailio (SER) - Development Mailing List <sr-dev@lists.kamailio.orgmailto:sr-dev@lists.kamailio.org>; giacomo.vacca@gmail.commailto:giacomo.vacca@gmail.com; M S <shaheryarkh@gmail.commailto:shaheryarkh@gmail.com>; camille.oudot@orange.commailto:camille.oudot@orange.com; Chandrabhan Kumar <chandrabhan.kumar@goldilocks-tech.commailto:chandrabhan.kumar@goldilocks-tech.com>; sr-users@lists.kamailio.orgmailto:sr-users@lists.kamailio.org Subject: SO_REUSEPORT
Hi all,
I want a help to understand if the reuse port feature is supported in the UDP sockets.
I tried to have a look into the code but could not find much detail,
The link provides the development information is available, but it does not talk about it.
Regards Sarju
_______________________________________________ Kamailio - Development Mailing List -- sr-dev@lists.kamailio.orgmailto:sr-dev@lists.kamailio.org To unsubscribe send an email to sr-dev-leave@lists.kamailio.orgmailto:sr-dev-leave@lists.kamailio.org Important: keep the mailing list in the recipients, do not reply only to the sender!