[asterisk-biz] IAX Channels limit on Asterisk 1.4.17

[Trixter aka Bret McDanel]

On Tue, 2008-01-15 at 23:31 -0800, Nitzan Kon wrote:
> After doing some googling I think I found your problem.. if you look in
> chan_iax2.c you'll see there is a hard-coded limit of 256 channels:


this limit is used in find_idle_thread(), looking there you will see
that it will first try to get an idle thread, if that fails then it will
try from the dynamic list, if that fails then it tries to create one
only if there are available threads.  There is no log entry created if
it cant make a new thread, especially because of the limit.  So at the
very least it should say why it cant make a thread.

These threads are made when some action is added to the scheduler, and
in socket_read().  The scheduler stuff seems a bit dodgy, rather than a
queue with 1 thread processing the queue, it will assign each scheduled
event a new thread.  

Because of the way you do things in UDP you cant spawn a new thread for
each connection on reception, instead you really have to have 1 thread
that receives all packets for all hosts and deal with them.  TCP is
different since you have a connected state, you can do like apache.  By
using 1 port like this, iax gets a bottleneck situation where it will
have all Rx packets go into a single thread, regardless of the number of
CPUs/cores you may have in your system.  So this is 1 of that, the
scheduler is the rest.  

While this may be part of the problem in higher than 256 channel counts,
its related to the scheduler and not the actual channel limits.  If you
try to schedule an action (such as a ping, reception from the jitter
buffer, register, and several other things) you may run out of scheduler
threads and that would cause a problem.  

The 'multi threaded scheduler' can of course be disabled more easily by
commenting 
#define SCHED_MULTITHREADED
in chan_iax2.c.  

If you do that you will notice that elsewhere in the code it will just
do stuff as opposed to trying to create a new thread to do it.  This may
result in that limit being removed, and would easily let you know if its
the multi-threaded scheduler that is to blame as opposed to something
else.

I do not know what performance problems may be caused by disabling the
multithreaded scheduler.  So if you do disable it, testing is certainly
a good thing.


-- 
Trixter http://www.0xdecafbad.com     Bret McDanel
Belfast +44 28 9099 6461        US +1 516 687 5200
http://www.trxtel.com the phone company that pays you!