From: Greg Banks <gnb@sgi.com>
To: Erik Walthinsen <omega@pdxcolo.net>
Cc: nfs@lists.sourceforge.net
Subject: Re: NAS server avalanche overload
Date: Thu, 4 Mar 2004 11:04:38 +1100 [thread overview]
Message-ID: <20040304000438.GA25910@sgi.com> (raw)
In-Reply-To: <1078351343.821.28.camel@localhost>
On Wed, Mar 03, 2004 at 02:02:23PM -0800, Erik Walthinsen wrote:
> Greg Banks said:
> > Are you using the "async" export option on the server? It causes
> > similar symptoms when used with large NFS writes. Use "sync".
>
> Mount options as reported by /proc/mounts are:
> rw,noatime,rsize=4096,wsize=4096,intr,soft,noac,tcp
And the export options are? cat /etc/exports on the server.
The noatime option has no effect over NFS. Your [rw]sizes are
really quite small, try 8K. Also, try turning off noac.
> I'm pretty sure the default here is async, as I had sync on there
> earlier and it actually caused a noticeable drop in performance.
So did you get the collapse with sync ?
> What I'm wondering is if the default bdflush settings are putting a hard
> cap on how much data can be write-cached, forcing the system to block
> writes too early. With 512MB of RAM, say half available as write-cache,
> even at the rate of 5MB/sec, we should be able to run for almost a
> minute with complete disk starvation before things start to wedge. And
> since this doesn't look like complete starvation at all (graphs show
> I/O's are completing the whole time), it should last even longer.
The problem I've seen is that the data is written out from the page
cache with the BKL held, which prevents any nfsd thread from waking up
and responding to incoming requests, and NFS traffic drops to zero.
In addition, if any of the nfsd's owned some other lock when this
happened, some local processes can be blocked too. This is an
inevitable result of the "async" export option.
> If anyone has any ideas on what to tweak in bdflush, it seems that there
> *is* some pattern in the spikes, with them occurring at 11:25pm and
> 12:00am every day for at least the last 3 days.
You could try reducing the 1st parameter in /proc/sys/vm/bdflush
to say 5 and decrease the 5th parameter by a similar factor. This
will activate kupdated more frequently and it will write data out
earlier. But, did I mention the "sync" export option?
Greg.
--
Greg Banks, R&D Software Engineer, SGI Australian Software Group.
I don't speak for SGI.
-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
_______________________________________________
NFS maillist - NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs
next prev parent reply other threads:[~2004-03-04 0:10 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-03-03 8:31 NAS server avalanche overload Erik Walthinsen
2004-03-03 22:02 ` Erik Walthinsen
2004-03-04 0:04 ` Greg Banks [this message]
2004-03-04 0:20 ` Erik Walthinsen
2004-03-04 1:40 ` Greg Banks
2004-03-04 2:17 ` Trond Myklebust
2004-03-04 4:39 ` Ian Kent
2004-03-04 5:31 ` Erik Walthinsen
2004-03-04 5:47 ` Greg Banks
2004-03-04 14:38 ` Ian Kent
[not found] <482A3FA0050D21419C269D13989C61130435DCCB@lavender-fe.eng.netapp.com>
2004-03-03 22:34 ` Erik Walthinsen
-- strict thread matches above, loose matches on Subject: below --
2004-03-04 2:07 Lever, Charles
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=20040304000438.GA25910@sgi.com \
--to=gnb@sgi.com \
--cc=nfs@lists.sourceforge.net \
--cc=omega@pdxcolo.net \
/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.