The Linux Kernel Mailing List
 help / color / mirror / Atom feed
From: Robert Derr <rderr@weatherflow.com>
To: Linus Torvalds <torvalds@osdl.org>
Cc: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Manfred Spraul <manfred@colorfullife.com>
Subject: Re: 2.6.13.3 Memory leak, names_cache
Date: Thu, 06 Oct 2005 15:24:13 -0400	[thread overview]
Message-ID: <434579DD.3000104@weatherflow.com> (raw)
In-Reply-To: <Pine.LNX.4.64.0510061150290.31407@g5.osdl.org>

Linus Torvalds wrote:
> On Thu, 6 Oct 2005, Robert Derr wrote:
>   
>> I'm having a problem with a memory leak in the kernel.  I'm running 2.6.13.3
>> from kernel.org on FC4 on a Dell  Poweredge 2850 Duel Xeon 3ghz with 2GB RAM.
>>     
>
> Just out of interest, do you have CONFIG_AUDIT_SYSCALL enabled? Does it go 
> away if you disable it?
>   
It looks like it is enabled.  CONFIG_AUDITSYSCALL=y in .config, right?
> Also, what filesystems do you use? And if you run
>
> 	while : ; do cat /proc/slabinfo | grep names_cache ; sleep 2; done
>
> in one terminal, can you see if you can find any correlation to some 
> particular action or behaviour that would seem to be part of leaking it?
>   
I'm not sure if I can find the action or behavior causing the problem.  
The server is the master node on a 14 computer cluster running a 
mesoscale weather forecasting package so there's a million things going 
on all the time.  I guess I could write a program to compare all the 
processes running against the names_cache and look for any correlation.

Here's the output of mount.  The drives are all ext3

/dev/sda2 on / type ext3 (rw)
/dev/proc on /proc type proc (rw)
/dev/sys on /sys type sysfs (rw)
/dev/devpts on /dev/pts type devpts (rw,gid=5,mode=620)
/dev/sda1 on /boot type ext3 (rw)
/dev/shm on /dev/shm type tmpfs (rw)
none on /proc/sys/fs/binfmt_misc type binfmt_misc (rw)
> It really shouldn't grow very big at all normally. Ie the counts are 
> normally something like a few tens of entries used or whatever - all the 
> allocations should basically be temporary, and your 200+ _thousand_ 
> entries are way out of line.
>
> If you can't find anything obvious, then we can try to figure out a way to 
> just print out the contents of your name entries, I bet that would give a 
> clue about who is allocating them. But there's also been various leak 
> debugging patches out there that may help.  Manfred may have pointers.
>
> 		Linus
>   
I'll look for those leak debugging patches.
Thanks for your time. 

Robert J Derr
Weatherflow, Inc.



  reply	other threads:[~2005-10-06 19:24 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-10-06 18:34 2.6.13.3 Memory leak, names_cache Robert Derr
2005-10-06 19:03 ` Linus Torvalds
2005-10-06 19:24   ` Robert Derr [this message]
2005-10-06 19:54     ` Linus Torvalds
2005-10-06 20:03 ` Rick Lindsley
2005-10-06 21:17   ` Robert Derr
2005-10-06 21:31   ` Linus Torvalds
2005-10-06 23:31     ` Al Viro

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=434579DD.3000104@weatherflow.com \
    --to=rderr@weatherflow.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=manfred@colorfullife.com \
    --cc=torvalds@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