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! _______________________________________________ --Bandwidth and Colocation Provided by http://www.api-digital.com-- asterisk-biz mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-biz
