[asterisk-users] ConfBridge performance problem...?

[Thorsten Göllner]

Did you check
asterisk -rx "core show translation recalc 10"

Am 06.02.2013 13:56, schrieb Thorsten Göllner:
> Sorry - I just read you alsways checked the cpu usage. Are all cores 
> at 100%? Is it the atserisk process which consumes it all?
>
> Am 06.02.2013 13:54, schrieb Thorsten Göllner:
>> Did you watch the cpu usage (for example with top)?
>> You have a board installed which does use dahdi? Did you check the 
>> command "dahdi_test"?
>> Maybe a (performance) problem of the software ec?
>>
>> Am 06.02.2013 11:13, schrieb Hristo Trendev:
>>> Hi,
>>>
>>> I have been experimenting with ConfBridge from the asterisk-11 
>>> stable SVN branch (and with 11.2.0 also) for the last 3 weeks and I 
>>> see a problem, which what I believe is performance related. I just 
>>> wanted to ask if someone else has made any tests and what is the 
>>> maximum number of participants that they've seen in a conference.
>>>
>>> I was never able to get more than 8 participants (mixed G722 and 
>>> G711a) on a conference (actually that's per server limit) with 
>>> almost all settings on default, except for dsp_drop_silence and 
>>> denoise which are enabled.
>>>
>>> I tested on Debian squeeze, 64-bit, quad-core Xeon server @2.4GHz 
>>> and also on another virtual server with similar processor (just one 
>>> core available to the VM). While this is not the latest and greatest 
>>> CPU, I would certainly expect it to handle more than 8 calls.
>>>
>>> To be honest, I was in fact able to get it working for up to 20 
>>> participants (most with G711), when I switched from 
>>> res_timing_timerfd to res_timing_dahdi and turned off denoise, but 
>>> that's still not normal I believe, especially with most participants 
>>> on mute and with dps_drop_silence enabled and nothing else running 
>>> on the server.
>>>
>>> The problem itself is, that once I get over the "critical" number of 
>>> participants, the voice starts to break up and it's impossible to 
>>> understand the person who's talking. This is certainly not bandwidth 
>>> related because all tests were made on the LAN and besides I could 
>>> see that the CPU was sometime close to 100%.
>>>
>>> Did someone observe something similar?
>>>
>>> BTW, once the first participant enters the conference I start seeing 
>>> probably over 50 messages per second saying:
>>>
>>> bridging.c:757 bridge_channel_join_multithreaded: Going into a 
>>> multithreaded waitfor for bridge channel 0x292d708 of bridge 0x28f3658