[asterisk-dev] Memory failure - channels in meetme

[Kevin P. Fleming]

On 11/10/2011 09:26 AM, Olle E. Johansson wrote:
>
> 2 nov 2011 kl. 14:57 skrev Kevin P. Fleming:
>
>> On 10/31/2011 09:03 AM, Olle E. Johansson wrote:
>>> Apologize for short memory. Kevin explained on #asterisk-dev the number of Dahdi channels involved in a meetme, but I forgot it and also forgot to copy his explanation. Can we please get the latest version for archives and memory refresh?
>>
>> I'll try :-)
>>
>> When a MeetMe conference is established (the first user joins), there is a DAHDI pseudo channel (not an Asterisk channel... no ast_channel structure here). This channel is used by MeetMe to retrieve the 'common' mixed audio to be sent to all non-talking members of the conference, rather than retrieving it individually for each non-talking member from their own conference channel. This allows for reduced encoding; if there are a number of non-talking conference members using the same codec, this audio can be encoded once and sent to all of them.
>>
>> If the first user in the conference is any type of Asterisk channel *other than* DAHDI, then a second DAHDI pseudo channel is opened (again, no ast_channel involved). This is used to feed that user's audio into the conference, and when they are a talker, provide the audio feed that should be sent to them. This same step is performed for any additional users who subsequently join the conference and are not DAHDI native channels.
>
> We currently see 71 meetme's and 818 file handles counted by lsof |grep dahdi|wc -l

A simpler way to be sure you are looking at only the relevant file 
handles would be:

$ lsof +d /dev/dahdi -p <PID of Asterisk process>


> You did not mention timer handles, but still if we have one or two participants per meetme, this doesn't make sense. Wonder if I can trust "lsof" to have unique handles - one per row.
>
> This worries us quite a lot sicne we had issues with reaching the 1024 limit earlier. We haven't had a chance to replace the kernel drivers with the new ones, but wonder if it's a bug that causing these many file handles in DAHDI - way more than what should be expected from your description.
>
> Any advice on how to debug this?

If the modified 'lsof' command above still produces similar counts of 
open file handles, I would suggest posting the output here so we can see 
if there is any obvious duplication or other problems.

-- 
Kevin P. Fleming
Digium, Inc. | Director of Software Technologies
Jabber: kfleming at digium.com | SIP: kpfleming at digium.com | Skype: kpfleming
445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
Check us out at www.digium.com & www.asterisk.org