[Top][All Lists]
[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. For about the first 5600 hits, the stats for memp
#4 look like this:<br>
<br>
m->avail: 8<br>
m->used: 2<br>
m->max: 2<br>
m->err: 0<br>
m->reclaimed: 0<br>
<br>
Then, suddenly:<br>
<br>
m->avail: 8<br>
m->used: 7<br>
m->max: 8<br>
m->err: 3<br>
m->reclaimed: 0<br>
<br>
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....<br>
<pre class="moz-signature" cols="$mailwrapcol">--
James Roth <a class="moz-txt-link-rfc2396E"
href="mailto:address@hidden"><address@hidden></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.]
- [lwip-users] Re: [lwip] lwIP 0.5.2 under heavy use, Jani Monoses, 2003/01/08
- [lwip-users] Re: [lwip] lwIP 0.5.2 under heavy use, Leon Woestenberg, 2003/01/08
- [lwip-users] Re: [lwip] lwIP 0.5.2 under heavy use, Paul Sheer, 2003/01/08
- [lwip-users] Re: [lwip] lwIP 0.5.2 under heavy use, James Roth, 2003/01/08
- [lwip-users] Re: [lwip] lwIP 0.5.2 under heavy use, Adam Dunkels, 2003/01/08
- [lwip-users] Re: [lwip] lwIP 0.5.2 under heavy use, Kieran Mansley, 2003/01/08
- [lwip-users] Re: [lwip] lwIP 0.5.2 under heavy use, Kieran Mansley, 2003/01/08
- [lwip-users] Re: [lwip] lwIP 0.5.2 under heavy use,
James Roth <=
- [lwip-users] Re: [lwip] lwIP 0.5.2 under heavy use, James Roth, 2003/01/09