<br><br><div class="gmail_quote">On Thu, Jul 22, 2010 at 1:16 AM, Olle E. Johansson <span dir="ltr"><<a href="mailto:oej@edvina.net">oej@edvina.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<br>
21 jul 2010 kl. 22.10 skrev Simon Perreault:<br>
<div class="im"><br>
> On 2010-07-21 16:14, Andreas Sikkema wrote:<br>
>> But using very high ulimit values to hide bugs is just bad by any<br>
>> measure. Leaking file descriptors will one day bite you hard, whether<br>
>> the limit is high or low and it will always be at a very inconvenient<br>
>> time. For some time I even had munin monitor an app for the number of<br>
>> file descriptors it had so I could restart it during a maintenance<br>
>> window. After doing that for a couple of weeks you really, really<br>
>> want the bug to be fixed.<br>
><br>
> I was assuming there was no leak.<br>
><br>
</div>If murf sends a report to asterisk-dev, you can safely assume there's a leak somewhere.<br>
I've heard about this, but have not experienced it myself.<br>
<br>
Steve, I would duplicate the system and run SIPP with a large number of calls. It's easy to check<br>
how many RTP sessions you should have - there are four ports per audio call. If "sip show channels"<br>
show 100 calls, you should have 200 inbound ports open for listening and 200 ports used for sending stuff.<br>
In addition to this you have the usual ports, but those are not many.<br>
<br>
If we have a file leak, it's worth tracking it down. From the ports reported, it sure smells like RTP/RTCP ports.<br></blockquote><div><br>Thanks, Olle.<br><br>I concur, it looks very much like a leak to me, And it does look likecalls contribute to the left-over open files,<br>
as yesterday, I had 252 open files, and today, I have 270.<br><br>I have copies of this virtual machine in several places in the cloud, and they pretty much only vary in configuration, and this system is the only one with this problem.<br>
Which leads me to think that the leak is associated either with a particular configuration, or perhaps to a particular<br>voip provider, or some combo of the two, or I'm just totally a bad guesser.<br><br>Today, "core show calls" says "192 calls processed", yesterday "127 calls processed", diff = 65 calls.<br>
open files today=270, yesterday=252, diff=18. So, whatever is happening, isn't happening on every call.<br>Maybe only incoming calls? Outgoing? using a particular IP provider? combo? who knows!<br><br>Unfortunately, this system is scheduled for termination soon... I may or may not find the problem in the time allotted.<br>
<br>WIll keep you all posted.<br><br>murf<br> <br></div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<font color="#888888"><br>
/O<br>
</font><div><div></div><div class="h5"><br>
<br>
--<br>
_____________________________________________________________________<br>
-- Bandwidth and Colocation Provided by <a href="http://www.api-digital.com" target="_blank">http://www.api-digital.com</a> --<br>
<br>
asterisk-dev mailing list<br>
To UNSUBSCRIBE or update options visit:<br>
<a href="http://lists.digium.com/mailman/listinfo/asterisk-dev" target="_blank">http://lists.digium.com/mailman/listinfo/asterisk-dev</a><br>
</div></div></blockquote></div><br><br clear="all"><br>-- <br>Steve Murphy<br>ParseTree Corp<br><br>