Hi Ali,

Kamailio's SIP message processing is accomplished by worker child processes which are forked when Kamailio starts. The number of these child processes is regulated by the 'children' core parameter:

http://www.kamailio.org/wiki/cookbooks/4.3.x/core#children

Any database operation is going to block one of these worker processes until it returns. It's not difficult to imagine 200-300 CPS clogging up the workers with database queries constantly, during which time no incoming SIP messages will be processed, as there is no process available to consume them. Worse yet, the dropped requests will cause retransmissions, adding to the deluge of messages experienced by Kamailio. Anyway, if your number of 'children' is very small, you may consider increasing it as the most immediate solution to your problem.

Due to the high-performance interprocess communication architecture, it is not viable to have a large number of these child processes. There is some disagreement as to where the useful limit lies, but it tends to hover around the number of available CPU cores ('nproc'). Our experience with high-throughput testing suggests that having a number of children greater than the number of "CPUs" in /proc/cpuinfo has diminishing returns.

Ultimately, however, the architecture is what it is. Handling high-CPS traffic through Kamailio is an art and a science. Some suggestions:

1. Reduce the latency of your database queries still further;

2. Use a caching layer like memcached or Redis to reduce database load;

3. Take advantage of Kamailio's asynchronous processing features:

http://kamailio.org/docs/modules/4.3.x/modules/async.html

#3 involves moving call processing out of the SIP worker processes and into another, separate thread pool, leaving the SIP worker processes free to process more messages.

-- Alex

On 07/28/2015 01:40 PM, Ali Taher wrote:

Hello,

I connected Kamailio to a postgresql database (through sqlops module) and fetching result from a table containing around 300K records , where time processing of the single query is taking around 12 ms.

I noticed that on huge load (around 200 – 300 calls per second) Kamailio is not processing all INVITE packets.

For instance , I initialized a counter in Kamailio that increments on every INVITE , and on the other hand I counted the number of INVITEs found in Wireshark.

I got a big difference (from 30K INVITES in Kamailio , I got 15K in Kamailio), though no errors were raised in kamailio log.

How can I proceed in order to detect the problem? L

Any help would be appreciated.

Regards,

Ali

---

SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users