[asterisk-dev] Asterisk scalability (was: Improve scheduler performance under high load)

[Klaus Darilion]

Venefax schrieb:
> Regarding scalability. I had an issue over the weekend when Asterisk got
> blocked when querying the database, and the amount of open calls rose to
> 1001, but then Asterisk froze and had to be killed with "killall asterisk".
> So there is a limit somewhere. The machine had plenty of memory available,
> but Asterisk did not seem to use it. So I would like to test any new code
> that breaks this barrier. I can probably hit 100 calls (SIP top SIP) any
> time. Right now I use one asterisk as distributor, no database, and several
> others to actually route the calls (wholesale model).

This sound like you have run out of file descriptors. Asterisk needs 
file descriptors for each port it opens (so having 2 SIP channels 
bridged, both with RTCP and video you need at least 8 file descriptors 
per call)

regards
klaus

> Federico  
> 
> -----Original Message-----
> From: asterisk-dev-bounces at lists.digium.com
> [mailto:asterisk-dev-bounces at lists.digium.com] On Behalf Of Joshua Colp
> Sent: Monday, February 16, 2009 8:47 AM
> To: Asterisk Developers Mailing List
> Subject: Re: [asterisk-dev] Asterisk scalability (was: Improve scheduler
> performance under high load)
> 
> ----- "Johansson Olle E" <oej at edvina.net> wrote:
> 
>> I think this together with the changes done by murf in the area of  
>> hash tables will mean that we done some major work to build a new  
>> generation of Asterisk that scales better than the old versions on the
>>  
>> current server architectures! Impressed!
>>
>> Now, can anyone start a discussion on the way we handle threads? If we
>>  
>> run on a quad-core or a system with dual quad core CPUs, we have  
>> capactiy for an enormous quantity of calls, with at least one thread 
>>
>> per call. Can a modern Linux/Unix thread scheduler handle 10 000  
>> threads efficently?
>>
> 
> Some work is also being done with the new bridging core to change this some.
> There is a bridging
> module called bridge_multiplexed which groups up to 4 bridges (or 8
> channels) into the same operating
> thread. We'll probably need to play with it to find the sweet spot on number
> of channels but hopefully
> this will help things.
>