From: Andrea Arcangeli <andrea@suse.de>
To: Dave Jones <davej@redhat.com>, Andrew Tridgell <tridge@osdl.org>,
linux-kernel <linux-kernel@vger.kernel.org>,
Andreas Gruenbacher <agruen@suse.de>,
Andrew Morton <akpm@osdl.org>
Subject: Re: memory leak in 2.6.11-rc2
Date: Tue, 25 Jan 2005 13:51:35 +0100 [thread overview]
Message-ID: <20050125125135.GO7587@dualathlon.random> (raw)
In-Reply-To: <20050125034546.GF13394@redhat.com>
On Mon, Jan 24, 2005 at 10:45:47PM -0500, Dave Jones wrote:
> On Tue, Jan 25, 2005 at 02:19:24PM +1100, Andrew Tridgell wrote:
> > The problem I've hit now is a severe memory leak. I have applied the
> > patch from Linus for the leak in free_pipe_info(), and still I'm
> > leaking memory at the rate of about 100Mbyte/minute.
> > I've tested with both 2.6.11-rc2 and with 2.6.11-rc1-mm2, both with
> > the pipe leak fix. The setup is:
>
> That's a little more extreme than what I'm seeing, so it may be
> something else, but my firewall box needs rebooting every
> few days. It leaks around 50MB a day for some reason.
> Given it's not got a lot of ram, after 4-5 days or so, it's
> completely exhausted its swap too.
>
> It's currently on a 2.6.10-ac kernel, so it's entirely possible that
> we're not looking at the same issue, though it could be something
> thats been there for a while if your workload makes it appear
> quicker than a firewall/ipsec gateway would.
> Do you see the same leaks with an earlier kernel ?
>
> post OOM (when there was about 2K free after named got oom-killed)
> this is what slabinfo looked like..
>
> dentry_cache 1502 3775 160 25 1 : tunables 120 60 0 : slabdata 151 151 0
> vm_area_struct 1599 2021 84 47 1 : tunables 120 60 0 : slabdata 43 43 0
> size-128 3431 6262 128 31 1 : tunables 120 60 0 : slabdata 202 202 0
> size-64 4352 4575 64 61 1 : tunables 120 60 0 : slabdata 75 75 0
> avtab_node 7073 7140 32 119 1 : tunables 120 60 0 : slabdata 60 60 0
> size-32 7256 7616 32 119 1 : tunables 120 60 0 : slabdata 64 64 0
What is avtab_node? there's no such thing in my kernel. But the above
can be ok. Can you show meminfo too after oom kill?
Just another datapoint my firewall runs a kernel based on 2.6.11-rc1-bk8 with
all the needed oom fixes and I've no problems on it yet. I run it oom
and this is what I get after the oom:
athlon:/home/andrea # free
total used free shared buffers cached
Mem: 511136 50852 460284 0 572 15764
-/+ buffers/cache: 34516 476620
Swap: 1052248 0 1052248
athlon:/home/andrea #
The above is sane, 34M is very reasonable for what's loaded there
(there's the X server running, named too, and various other non standard
daemons, one even has a virtual size of >100m so it's not a tiny thing),
so I'm quite sure I'm not hitting a memleak, at least not on the
firewal. No ipsec on it btw, and it's a pure IDE without anything
special, just quite a few nics and USB usermode running all the time.
athlon:/home/andrea # uptime
1:34pm up 2 days 12:08, 1 user, load average: 0.98, 1.13, 0.54
athlon:/home/andrea # iptables -L -v |grep -A2 FORWARD
Chain FORWARD (policy ACCEPT 65 packets, 9264 bytes)
pkts bytes target prot opt in out source destination
3690K 2321M block all -- any any anywhere anywhere
athlon:/home/andrea #
So if there's a memleak in rc1-bk8, it's probably not in the core of the
kernel, but in some driver or things like ipsec. Either that or it broke
after 2.6.11-rc1-bk8. The kernel I'm running is quite heavily patched
too, but I'm not aware of any memleak fix in the additional patches.
Anyway I'll try again in a few days to verify it goes back down again to
exactly 34M of anonymous/random and 15M of cache.
No apparent problem on my desktop system either, it's running the same
kernel with different config.
If somebody could fix the kernel CVS I could have a look at the
interesting changesets between 2.6.11-rc1-bk8 and 2.6.11-rc2.
next prev parent reply other threads:[~2005-01-25 12:52 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-01-20 2:01 [ea-in-inode 0/5] Further fixes Andreas Gruenbacher
2005-01-20 2:01 ` [patch 3/5] Documentation fix Andreas Gruenbacher
2005-01-20 2:01 ` [patch 4/5] Fix i_extra_isize check Andreas Gruenbacher
2005-01-20 2:01 ` [patch 1/5] No lock needed when freeing inode Andreas Gruenbacher
2005-01-20 2:01 ` [patch 2/5] Set the EXT3_FEATURE_COMPAT_EXT_ATTR for in-inode xattrs Andreas Gruenbacher
2005-01-20 2:01 ` [patch 5/5] Disallow in-inode attributes for reserved inodes Andreas Gruenbacher
2005-01-20 12:16 ` Andreas Dilger
2005-01-20 13:29 ` Andreas Gruenbacher
2005-01-20 23:05 ` Andreas Dilger
2005-01-21 0:36 ` Andreas Gruenbacher
2005-01-21 22:58 ` [ea-in-inode 0/5] Further fixes Stephen C. Tweedie
2005-01-21 23:46 ` Andreas Gruenbacher
2005-01-23 13:22 ` Andrew Tridgell
2005-01-23 22:09 ` Andrew Tridgell
2005-01-23 22:58 ` Andreas Gruenbacher
2005-01-23 23:32 ` Andreas Gruenbacher
2005-01-24 11:24 ` Andrew Tridgell
2005-01-24 11:42 ` Christoph Hellwig
2005-01-24 14:11 ` Andreas Gruenbacher
2005-01-25 3:19 ` memory leak in 2.6.11-rc2 Andrew Tridgell
2005-01-25 3:20 ` Randy.Dunlap
2005-01-25 3:31 ` Andrew Tridgell
2005-01-25 4:48 ` Andrew Tridgell
2005-01-25 6:06 ` Andrew Morton
2005-01-25 11:35 ` Andrew Tridgell
2005-01-25 12:11 ` Nick Piggin
2005-01-25 3:45 ` Dave Jones
2005-01-25 12:51 ` Andrea Arcangeli [this message]
2005-01-25 13:31 ` Andreas Gruenbacher
2005-01-25 13:55 ` Andrea Arcangeli
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=20050125125135.GO7587@dualathlon.random \
--to=andrea@suse.de \
--cc=agruen@suse.de \
--cc=akpm@osdl.org \
--cc=davej@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=tridge@osdl.org \
/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