All of lore.kernel.org
 help / color / mirror / Atom feed
From: Anders Saaby <as@cohaesio.com>
To: William Lee Irwin III <wli@holomorphy.com>
Cc: linux-kernel@vger.kernel.org, joe@unthought.net,
	Gene Heskett <gene.heskett@verizon.net>,
	Hugh Dickins <hugh@veritas.com>
Subject: Re: oom-killer 2.6.8.1
Date: Tue, 24 Aug 2004 17:55:04 +0200	[thread overview]
Message-ID: <200408241755.05149.as@cohaesio.com> (raw)
In-Reply-To: <20040824154131.GM2793@holomorphy.com>

On Tuesday 24 August 2004 17:41, William Lee Irwin III wrote:
> On Tue, Aug 24, 2004 at 11:30:15AM +0200, Anders Saaby wrote:
> > OK - I now have some additional info regarding the slapinfo/oom-killer
> > issue.
> > As I wrote earlier this server is a storage server providing NFS storage
> > to a number of webservers - ondisk filesystem is xfs, kernel = 2.6.8.1.
> > At 03:00 some logrotate scripts runs throug a lot of files. It appears
> > that this is what is using the slabs (see this graph, K = M, so max used
> > slab is approx. 700M)
> > http://saaby.com/slabused.gif (values are from /proc/meminfo)
> > These are the values (from slabinfo, active_objs), which changed
> > remarkably from 03:00 to 06:00:
> > 03:00:        06:00:
> > xfs_chashlist  91297    xfs_chashlist     151994
> > xfs_inode     243791    xfs_inode         586780
> > linvfs_icache 243791    linvfs_icache     586807
> > dentry_cache  196033    dentry_cache      430609
>
> xfs has some known bad slab behavior. I think punting this in the
> direction of xfs mailing lists may be useful.
>
OK, interesting! - I will do that.

> On Tue, Aug 24, 2004 at 11:30:15AM +0200, Anders Saaby wrote:
> > The server crashed every night at approx. 03:00 to 04:00 - until last
> > night where we changed:
> > vm.min_free_kbytes from default (approx. 900K) to
> > vm.min_free_kbytes=32768 (32M)
> > This seems to solve the problem - Does this make any sense to you? - Or
> > just pure luck?
>
> I guess it makes some sense since it refuses to let slab cut into the
> very last bits of RAM. If you're getting temporarily heavily fragmented
> with active references it may mean the difference between the box
> livelocking/deadlocking and making forward progress.
>
Sounds right.

Thanks for your help! :-)

/Saaby

>
> -- wli

      reply	other threads:[~2004-08-24 15:55 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-08-18 12:55 oom-killer 2.6.8.1 Anders Saaby
2004-08-18 13:57 ` Gene Heskett
2004-08-18 14:11   ` Jakob Oestergaard
2004-08-18 14:46     ` Hugh Dickins
2004-08-18 14:14   ` Anders Saaby
2004-08-18 14:05 ` William Lee Irwin III
2004-08-18 14:24   ` Anders Saaby
2004-08-18 21:11     ` William Lee Irwin III
2004-08-19 12:58       ` Anders Saaby
2004-08-24  9:30       ` Anders Saaby
2004-08-24 15:41         ` William Lee Irwin III
2004-08-24 15:55           ` Anders Saaby [this message]

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=200408241755.05149.as@cohaesio.com \
    --to=as@cohaesio.com \
    --cc=gene.heskett@verizon.net \
    --cc=hugh@veritas.com \
    --cc=joe@unthought.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=wli@holomorphy.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 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.