lwip-users
[Top][All Lists]
Advanced
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[lwip-users] Re: [lwip] lwIP 0.5.2 under heavy use

From: James Roth
Subject: [lwip-users] Re: [lwip] lwIP 0.5.2 under heavy use
Date: Thu, 09 Jan 2003 00:00:51 -0000 
--------------050802070404010107000605
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Kieran Mansley wrote:

>On Tue, 12 Mar 2002, James Roth wrote:
>
>>To clarify, this is the message that appears just before failure:
>>
>>    memp_malloc: out of memory in pool 4
>>
>>Looks like 4 is MEMP_TCP_PCB_LISTEN, my MEMP_NUM_TCP_PCB_LISTEN is 8.
>> Why would this run out after thousands of successful, sequential
>>connections?
>>
>
>I've not heavily tested it, but I'm not surprised that you see something
>like this after a long time, as some parts of the code such as the sockets
>interface haven't seen a great deal of action.  Also, it's still being
>developed so bugs will surface every now and then.
>
>As to how to track it down...  For you to run out of memory in the listen
>pcb pool, the application must have more than 8 listening sockets.  If it
>doesn't, it must have opened 8 in total, and there is a bug in the
>closing/reclaiming of listening sockets so they don't get freed properly.
>I know apache does start up a new process every now and then (to replace
>an old one - it does this to ensure any memory leaks are short lived), or
>have many processes on the go listening for connections, and it can
>increase the number it has in order to meet demand.  Perhaps this is why
>it is reaching the limit of 8 listening connections.  I'd take a look at
>tcp_listen, perhaps put some tracing in to see how often it is getting
>called and when.  This might give a clue as to why it is running out of
>this particular resource.
>
>Hope that helps - it's a bit vague, but might give you somewhere to start!
>
>Kieran
>
>[This message was sent through the lwip discussion list.]
>

I increased mem pool #8 so that it no longer runs out.

Ok, I turned on stats.  For about the first 5600 hits, the stats for 
memp #4 look like this:

    m->avail: 8
    m->used: 2
    m->max: 2
    m->err: 0
    m->reclaimed: 0

Then, suddenly:

   m->avail: 8
   m->used: 7
   m->max: 8
   m->err: 3
   m->reclaimed: 0

and boom.   It never recovers.  This always happens about 700 seconds 
after booting.  A sudden increase of 2 or less m->used to more than 8. 
 Hmmm....

-- 
James Roth <address@hidden>
Shugyo Design Technologies
http://www.shugyodesign.com/



--------------050802070404010107000605
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

<html>
<head>
</head>
<body>
Kieran Mansley wrote:<br>
<blockquote type="cite" cite="mid:address@hidden">
  <pre wrap="">On Tue, 12 Mar 2002, James Roth wrote:<br><br></pre>
  <blockquote type="cite">
    <pre wrap="">To clarify, this is the message that appears just before 
failure:<br><br>    memp_malloc: out of memory in pool 4<br><br>Looks like 4 is 
MEMP_TCP_PCB_LISTEN, my MEMP_NUM_TCP_PCB_LISTEN is 8.<br> Why would this run 
out after thousands of successful, sequential<br>connections?<br></pre>
    </blockquote>
    <pre wrap=""><!----><br>I've not heavily tested it, but I'm not surprised 
that you see something<br>like this after a long time, as some parts of the 
code such as the sockets<br>interface haven't seen a great deal of action.  
Also, it's still being<br>developed so bugs will surface every now and 
then.<br><br>As to how to track it down...  For you to run out of memory in the 
listen<br>pcb pool, the application must have more than 8 listening sockets.  
If it<br>doesn't, it must have opened 8 in total, and there is a bug in 
the<br>closing/reclaiming of listening sockets so they don't get freed 
properly.<br>I know apache does start up a new process every now and then (to 
replace<br>an old one - it does this to ensure any memory leaks are short 
lived), or<br>have many processes on the go listening for connections, and it 
can<br>increase the number it has in order to meet demand.  Perhaps this is 
why<br>it is reaching the limit of 8 listening connections.  I'd take a look 
at<br
>tcp_listen, perhaps put some tracing in to see how often it is 
>getting<br>called and when.  This might give a clue as to why it is running 
>out of<br>this particular resource.<br><br>Hope that helps - it's a bit vague, 
>but might give you somewhere to start!<br><br>Kieran<br><br>[This message was 
>sent through the lwip discussion list.]<br></pre>
    </blockquote>
    <br>
I increased mem pool #8 so that it no longer runs out.<br>
    <br>
Ok, I turned on stats. &nbsp;For about the first 5600 hits, the stats for memp
#4 look like this:<br>
    <br>
&nbsp;&nbsp;&nbsp; m-&gt;avail: 8<br>
&nbsp;&nbsp;&nbsp; m-&gt;used: 2<br>
&nbsp;&nbsp;&nbsp; m-&gt;max: 2<br>
&nbsp;&nbsp;&nbsp; m-&gt;err: 0<br>
&nbsp;&nbsp;&nbsp; m-&gt;reclaimed: 0<br>
    <br>
Then, suddenly:<br>
    <br>
&nbsp;&nbsp; m-&gt;avail: 8<br>
&nbsp;&nbsp; m-&gt;used: 7<br>
&nbsp;&nbsp; m-&gt;max: 8<br>
&nbsp;&nbsp; m-&gt;err: 3<br>
&nbsp;&nbsp;&nbsp;m-&gt;reclaimed: 0<br>
    <br>
and boom. &nbsp; It never recovers. &nbsp;This always happens about 700 seconds 
after
booting. &nbsp;A sudden increase of 2 or less m-&gt;used to more than 8. 
&nbsp;Hmmm....<br>
    <pre class="moz-signature" cols="$mailwrapcol">-- 
James Roth <a class="moz-txt-link-rfc2396E" 
href="mailto:address@hidden";>&lt;address@hidden&gt;</a>
Shugyo Design Technologies
<a class="moz-txt-link-freetext" 
href="http://www.shugyodesign.com/";>http://www.shugyodesign.com/</a>
</pre>
    <br>
    </body>
    </html>

--------------050802070404010107000605--

[This message was sent through the lwip discussion list.]
reply via email to
[Prev in Thread] Current Thread [Next in Thread]