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

[Kaloyan Kovachev]

check asterisk.conf for 'maxfiles' option - it is 1000 by default

On Mon, 16 Feb 2009 08:54:04 -0500, Venefax wrote
> 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).
> 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.
> 
> -- 
> Joshua Colp
> Digium, Inc. | Software Developer
> 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
> Check us out at:  www.digium.com  & www.asterisk.org
> 
> _______________________________________________
> --Bandwidth and Colocation Provided by http://www.api-digital.com--
> 
> asterisk-dev mailing list
> To UNSUBSCRIBE or update options visit:
>    http://lists.digium.com/mailman/listinfo/asterisk-dev
> 
> _______________________________________________
> --Bandwidth and Colocation Provided by http://www.api-digital.com--
> 
> asterisk-dev mailing list
> To UNSUBSCRIBE or update options visit:
>    http://lists.digium.com/mailman/listinfo/asterisk-dev