[asterisk-dev] Memory failure - channels in meetme

[Matthew Jordan]

Sorry if this is throwing out an obvious suggestion, but have you tried compiling with DEBUG_FD_LEAKS and use core show fd to monitor the file descriptors?  It should show everything allocated during a MeetMe conference, and you could query periodically to see if new file descriptors are being allocated or left dangling after a MeetMe conference ends.  I wouldn't want to try it for 71 simultaneous conferences, but for a single conference with one or two users it should point towards what MeetMe is doing.

Matthew Jordan
Digium, Inc. | Software Developer
445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
Check us out at: http://digium.com & http://asterisk.org

----- Original Message -----
From: "Olle E. Johansson" <oej at edvina.net>
To: "Asterisk Developers Mailing List" <asterisk-dev at lists.digium.com>
Sent: Thursday, November 10, 2011 9:26:12 AM
Subject: Re: [asterisk-dev] Memory failure - channels in meetme


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

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?
/O
--
_____________________________________________________________________
-- 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