All of lore.kernel.org
 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.