All of lore.kernel.org
 help / color / mirror / Atom feed
From: "JP Howard" <jh_lists@fastmail.fm>
To: Eric Whiting <eric_whiting@amis.com>, Oleg Drokin <green@namesys.com>
Cc: ReiserFS List <reiserfs-list@namesys.com>
Subject: Re: file-nr, file-max, and ReiserFS
Date: Tue, 22 Oct 2002 20:20:05 UT	[thread overview]
Message-ID: <20021022202005.18E47DF81@server2.fastmail.fm> (raw)

On Tue, 22 Oct 2002 08:02:10 -0600, "Eric Whiting"
<eric_whiting@amis.com> said:
> JP,
> 
> Were both boxes running cyrus/postfix? Postfix relies heavily on several
> different mailqueue dirs.
> 
The source of the problem was actually a Postfix bug, which Wietse had
provided a patch for on the mailing list, but I hadn't yet applied. The
bug caused an infinite loop that opened thousands of LMTP processes on
our backend, causing it to run out of file handles. It was nothing to do
with ReiserFS.
> 
> Oleg Drokin wrote:
> > 
> > Hello!
> > 
> > On Tue, Oct 22, 2002 at 04:41:17AM +0000, JP Howard wrote:
> > 
> > > The ReiserFS server (running Cyrus and Postfix) has been hitting our max
> > > FDs (/proc/sys/fs/file-max) a few times, which is set at 90,000. However,
> > > we have an Ext3 server with almost the same # of users and overall load,
> > > and it has only hit 20,000 open files (according to
> > > /proc/sys/fs/file-nr).
> > 
> > Filesystems itself does not consume file descriptors.
> > 
> > > Does ReiserFS use more file handles for some reason? Is there any
> > 
> > Not likely.
> > 
> > > downside to setting file-max to something really big to avoid running out
> > > of FDs? Do you think that this may actually indicate some problem with
> > 
> > More fds you use, more RAM they consume ;)
> > 
> > > our configuration, or this normal for ReiserFS?
> > 
> > There must be the difference between your ext3 based and reiserfs based systems
> > that will explain FD usage difference. Something in userspace most probably.
> > 
> > > Also, I checked with `lsof | wc -l` to see how many files it reported as
> > > open. On the ReiserFS server it only showed 45,000 files as open (when
> > > the system had actually used all 90,000 handles). On the Ext3 server is
> > 
> > If the system is really used all 90000  handles, you would not be able to look
> > at /proc/sys/fs/file-nr content, so perhaps the peak was over already at a time
> > you reviewed it?
> > 
> > > showed 30,000 files as open (when the system had actually only used
> > > 20,000 handles according to file-nr). I guess I'm wrong to be thinking
> > > that lsof and file-nr should show the same number of open files, but
> > > could someone explain why?
> > 
> > Well, file descriptors might be shared between processes/threads, but
> > lsof does not know about this
> > 
> > Bye,
> >     Oleg
> 

             reply	other threads:[~2002-10-22 20:20 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-10-22 20:20 JP Howard [this message]
  -- strict thread matches above, loose matches on Subject: below --
2002-10-22 10:10 file-nr, file-max, and ReiserFS JP Howard
2002-10-22  4:41 JP Howard
2002-10-22  6:33 ` Oleg Drokin

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=20021022202005.18E47DF81@server2.fastmail.fm \
    --to=jh_lists@fastmail.fm \
    --cc=eric_whiting@amis.com \
    --cc=green@namesys.com \
    --cc=reiserfs-list@namesys.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.