lkml.org 
[lkml]   [2005]   [May]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: How to diagnose a kernel memory leak

(Please always do reply-to-all)

Bruce Guenter <bruceg@em.ca> wrote:
>
> On Mon, May 09, 2005 at 10:29:21AM +0200, Alexander Nyberg wrote:
> > the patch below might help as it works on a lower
> > level. It accounts for bare pages in the system available
> > from /proc/page_owner. So a cat /proc/page_owner > tmpfile would be good
> > when the system starts to go low. There's a sorting program in
> > Documentation/page_owner.c used to sort the rather large output.
>
> I've been running this for a day and a half now, and a few hundred megs
> of memory is now missing:
>
> # free
> total used free shared buffers cached
> Mem: 2055648 2001884 53764 0 259024 868484
> -/+ buffers/cache: 874376 1181272
> Swap: 1028152 56 1028096
>
> I've put the output from the sorting program up at
> http://untroubled.org/misc/page_owner_sorted
>
> Is this useful information yet, or is there still too much in cached
> pages to really identify the source?

It all looks pretty innocent. Please send the contents of /proc/meminfo
rather than the `free' output. /proc/meminfo has much more info.
Sometimes /proc/vmstat is also useful.

If the /proc/meminfo output indicates that there are a lot of slab pages
then /proc/slabinfo should be looked at.


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-05-13 02:22    [W:1.263 / U:0.104 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site