Summary:ASTERISK-10694: Asterisk core not multitreading sip-to-sip calls
Reporter:bcoppens (bcoppens)Labels:
Date Opened:2007-11-13 10:06:07.000-0600Date Closed:2011-06-07 14:02:56
Versions:Frequency of
Description:Presently we are running asterisk in an sip-to-sip environment. In this scenario, each call is using the following path:
G729 client -> [asterisk core] -> G729 client (no transcoding, with canreinvite= yes).
For a certain amount of traffic, we have observed that CPU 0 is havely loaded while the other CPU's 1,2 and 3 remain idle.
DL360 G4  2* dual-core running Linux 2.6.18-8.el5 #1 SMP Fri Jan 26 14:15:21 EST 2007 i686 i686 i386 GNU/Linux
Asterisk 1.4.13 built by root @ ast2-gos2-be on a i686 running Linux on 2007-10-15 11:33:09 UTC

We retrieved the following stats for 120 simultenous sip-to-sip calls
05:42:26 PM  CPU   %user   %nice    %sys %iowait    %irq   %soft  %steal   %idle    intr/s
05:42:31 PM  all    0.95    0.00    2.40    0.00    0.15    0.85    0.00   95.65  11291.40
05:42:31 PM    0    3.60    0.00    9.60    0.00    0.40    3.60    0.00   82.80  10280.60
05:42:31 PM    1    0.00    0.00    0.00    0.00    0.20    0.00    0.00  100.00     10.80
05:42:31 PM    2    0.00    0.00    0.00    0.00    0.00    0.00    0.00  100.00      0.00
05:42:31 PM    3    0.00    0.00    0.00    0.00    0.00    0.00    0.00  100.00   1000.40

We are from the opinion that we should make the asterisk core multithreaded.
This would allow us to handle *3 more calls.
Comments:By: Jason Parker (jparker) 2007-11-13 10:13:47.000-0600

Asterisk is already very heavily multi-threaded.

By: Russell Bryant (russell) 2007-11-13 13:44:20.000-0600

What you probably want is for chan_sip to handle signalling with a thread pool, as opposed to a single thread.  In that case, it's certainly a feature request, and not something appropriate for the bug tracker.

By: bcoppens (bcoppens) 2007-11-14 03:12:29.000-0600

You are closing the case without allowing me to react on your statement.
I am running asterisk in differnt modes (including multiple setups with TDM Digium cards). But in this simple sip-to-sip mode, Asterisk is totally not multithreaded. I don't know if it is related to the SIP signaling thread or to the RTP handling thread(fragmentation/defragmentation).
Now you are relating the above to a feature request while am seeing this a huge limitation.
How can we proceed with this discussion?

By: Olle Johansson (oej) 2007-11-14 06:45:52.000-0600

Interesting. have a customer reporting the same issue.

By: Olle Johansson (oej) 2007-11-14 06:46:16.000-0600

coppens_b: Which Linux are you using?

By: Russell Bryant (russell) 2007-11-14 12:29:05.000-0600

You said that you have canreinvite=yes with G.729 on both sides.  In that case, there isn't any RTP processing going on.  So, while there is a thread for every single call, they sit idle most of the time.  The one thread doing most of the work is the single incoming SIP signalling processing thread.

In the CPU load output you posted, the first CPU is still 83% idle.  Have you loaded it more than that?

If you would like to continue this discussion, let's do it on the asterisk-dev mailing list.  We really just try to avoid using the bug tracker as a discussion forum.  There are more people on the -dev list that can contribute to this discussion.

By: bcoppens (bcoppens) 2007-11-15 03:33:05.000-0600

I was wrong about the canreivite. We are relaying RTP onto the Asterisk - with canreinvite = no. My appologies for this typo.

From my opinion, it is the RTP handling which is causing the high load on CPU 0.
The above mentioned CPU snaphot was retrieved during normal working hours. We can clearly see higher volumes/load on CPU 0 during the peak (while the other CPU's are idle).
The RTP thread is probably the most important one. We encountered a huge dimensioning issue. Don't you agree?

What can I do to bring this to someone's attention.

I am using RH5 enterprise 2.6.18-8.el5 #1 SMP Fri Jan 26 14:15:21 EST 2007 i686 i686 i386 GNU/Linux

By: Olle Johansson (oej) 2007-11-15 03:41:39.000-0600

coppens_b: Let's take this off the tracker since Russell decided to do that until we have more information. Please e-mail me on oej@edvina.net to discuss this issue. Thanks.

By: Russell Bryant (russell) 2007-11-15 08:45:26.000-0600

There is no reason to discuss this issue in private.

Like I said before, the bug tracker is a really bad discussion forum.  For issues that need a decent amount of discussion and more eyes on the issue, the asterisk-dev mailing list is a much better place to start.  The issue will get more eyes, and makes it easier to keep track of a discussion.

I would like to pursue the issue, but I just want to move the discussion there.