public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: "William M. Shubert" <wms@igoweb.org>
To: "Matthew G. Marsh" <mgm@paktronix.com>,
	linux-kernel <linux-kernel@vger.kernel.org>
Subject: Re: Leak in network memory?
Date: Mon, 30 Jul 2001 18:40:29 -0700	[thread overview]
Message-ID: <3B660C8D.2080004@igoweb.org> (raw)
In-Reply-To: <Pine.LNX.4.31.0107300939420.14419-100000@netmonster.pakint.net>

Thanks for your response. I think that we have different problems though 
- my application is not growing at all, so it doesn't seem to be a glibc 
problem. Instead the kernel is refusing my "write()" calls with EAGAIN 
even though I know that I have written only a few kbytes and my output 
buffer size is set to 64K. Because this took 60+ days to start 
happening, I'm guessing that the kernel network code is either leaking 
memory or else is miscounting its memory consumed over time...what I 
really need to know is what I can do to confirm or refute this guess. It 
is also possible of course that there is no leak but my kernel has the 
"network takes too much memory" threshold set too low (and I was just 
lucky until now and didn't see the problem). I have looked at 
"/proc/sys/net/ipv4/tcp_mem", and it claims that it would take 48640 
pages (=200MB) before the TCP stack starts feeling memory pressure. I 
know that my TCP stack is not using this much memory, because I have 
only 256MB in the system and 150MB is under "active" in /proc/meminfo 
(I'm assuming this total does not include TCP data?)...so how can I 
check how much the TCP stack thinks it is currently using, and why it is 
refusing my "write()" calls?

Matthew G. Marsh wrote:

>On Sun, 29 Jul 2001, William M. Shubert wrote:
>
>>...At first it ran fine, but now after an uptime of 67 days
>>I'm starting to see strange problems. It seems as if only a very small
>>amount of memory can be held in the output buffer of each socket, even
>>though they are still set to 64KB!
>>...
>>I tried to trace through the
>>kernel code to see why the kernel would be refusing to give me the
>>buffering that I ask for, and it looks like if the network code thinks
>>that it is using too much memory, then it will behave this way. I'm not
>>100% sure of this, though...which is why I'm posting this message.
>>
>Worse here - the app keeps adding memory and the size of the memory is
>almost exactly equal to the amount of data transferred in (plus a few
>bytes of overhead). This memory is permanently cached and never released.
>We have an open case with RH ....
>
>>Does anybody have any hints on how I can track down exactly why my
>>output buffers aren't working? I see lots of /proc info related to
>>network parameters, but there is little documentation on them.
>>
>We were using the 2.4.5 kernel and were told to go back to the original
>kernel and it got worse. ?? When I find out more - looks like a memory
>leak in the glibc right now but... - I will let you know.
>
-- 

Bill Shubert (wms@igoweb.org) <mailto:wms@igoweb.org>
http://www.igoweb.org/~wms/ <http://igoweb.org/%7Ewms/>




  reply	other threads:[~2001-07-31  1:40 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-07-30  3:27 Leak in network memory? William M. Shubert
2001-07-30 14:46 ` Matthew G. Marsh
2001-07-31  1:40   ` William M. Shubert [this message]
2001-08-02 22:22 ` Alexey Kuznetsov
2001-08-08 12:49   ` Dipak
2001-08-08 13:54     ` David S. Miller

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=3B660C8D.2080004@igoweb.org \
    --to=wms@igoweb.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mgm@paktronix.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox