public inbox for linux-xfs@vger.kernel.org
 help / color / mirror / Atom feed
From: Eric Sandeen <sandeen@sandeen.net>
To: Poul Petersen <petersen@strands.com>
Cc: xfs@oss.sgi.com
Subject: Re: Slab memory usage
Date: Fri, 24 Apr 2009 20:01:37 -0500	[thread overview]
Message-ID: <49F260F1.4030503@sandeen.net> (raw)
In-Reply-To: <73EE3FB2-381F-43F1-82C1-FA4C020E7C02@strands.com>

Poul Petersen wrote:
> 	I'm running Debian Lenny with kernel 2.6.26-1-amd64 and  
> xfsprogs-2.9.8-1. I've been having a problem with the amount of slab  
> memory that XFS seems to be consuming when running a rsync backup job,  
> a du, or other file-system intensive programs. Below is an example of  
> the output of slabtop and /proc/meminfo. I'm running a tool that  
> monitors free memory space, and it starts generating alerts, though I  
> don't blame it when the SLAB is running at 50% of memory!
> 
> 	When the process finishes, the memory usually frees up over a period  
> of several hours. However, on a similar system, even 24 hours after  
> the rsync job finished, the slab never freed up. On that machine, if I  
> run:
> 
> echo 2 > /proc/sys/vm/drop_caches
> 
> 	Then the slab goes down to something more like 1% or 2% of system  
> RAM. Any ideas what is causing this behaviour? And how I might  
> alleviate it?
> 
> Thanks,
> 
> -poul
> 
> slabtop
> =======
> 
>   Active / Total Objects (% used)    : 7684622 / 7875871 (97.6%)
>   Active / Total Slabs (% used)      : 720661 / 720662 (100.0%)
>   Active / Total Caches (% used)     : 105 / 176 (59.7%)
>   Active / Total Size (% used)       : 2683658.81K / 2702989.38K (99.3%)
>   Minimum / Average / Maximum Object : 0.02K / 0.34K / 4096.00K
> 
>    OBJS ACTIVE  USE OBJ SIZE  SLABS OBJ/SLAB CACHE SIZE NAME
> 1933952 1933787  99%    0.44K 241744        8    966976K xfs_inode
> 1933918 1933787  99%    0.56K 276274        7   1105096K xfs_vnode
> 1361008 1359980  99%    0.20K  71632       19    286528K dentry


o/~ the dentry's connected to the ... v-node, the v-node's connected to
the ... i-node .... o/~

This is really mostly the linux vfs hanging onto the dentries.  This in
turn pins the inodes and related xfs structures.

But, your memory is there for caching, most of the time.  If it's not
(mostly) used, then it's wasted.  If the memory is needed for other
purposes, the vfs frees the cached dentries, which in turn frees the
related structures.  This really isn't necessarily indicative of a problem.

There are some tunables* you could play with to change this behavior if
you like, but unless you are actually seeing performance problems, I
wouldn't be too concerned.

-Eric


*from Documentation/sysctl/vm.txt:

vfs_cache_pressure
------------------

Controls the tendency of the kernel to reclaim the memory which is used
for caching of directory and inode objects.

At the default value of vfs_cache_pressure=100 the kernel will attempt
to reclaim dentries and inodes at a "fair" rate with respect to
pagecache and swapcache reclaim.  Decreasing vfs_cache_pressure causes
the kernel to prefer to retain dentry and inode caches.  Increasing
vfs_cache_pressure beyond 100 causes the kernel to prefer to reclaim
dentries and inodes.

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

  reply	other threads:[~2009-04-25  1:01 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-04-24 23:01 Slab memory usage Poul Petersen
2009-04-25  1:01 ` Eric Sandeen [this message]
2009-04-26 21:51   ` Michael Monnerie
2009-04-27  8:40     ` Josef 'Jeff' Sipek

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=49F260F1.4030503@sandeen.net \
    --to=sandeen@sandeen.net \
    --cc=petersen@strands.com \
    --cc=xfs@oss.sgi.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