From: Jakob Oestergaard <jakob@unthought.net>
To: Trond Myklebust <trond.myklebust@fys.uio.no>
Cc: Greg Banks <gnb@sgi.com>, linux-kernel@vger.kernel.org
Subject: Re: bdflush/rpciod high CPU utilization, profile does not make sense
Date: Sat, 9 Apr 2005 23:35:49 +0200 [thread overview]
Message-ID: <20050409213549.GW347@unthought.net> (raw)
In-Reply-To: <1112890671.10366.44.camel@lade.trondhjem.org>
On Thu, Apr 07, 2005 at 12:17:51PM -0400, Trond Myklebust wrote:
> to den 07.04.2005 Klokka 17:38 (+0200) skreiv Jakob Oestergaard:
>
> > I tweaked the VM a bit, put the following in /etc/sysctl.conf:
> > vm.dirty_writeback_centisecs=100
> > vm.dirty_expire_centisecs=200
> >
> > The defaults are 500 and 3000 respectively...
> >
> > This improved things a lot; the client is now "almost not very laggy",
> > and load stays in the saner 1-2 range.
>
> OK. That hints at what is causing the latencies on the server: I'll bet
> it is the fact that the page reclaim code tries to be clever, and uses
> NFSv3 STABLE writes in order to be able to free up the dirty pages
> immediately. Could you try the following patch, and see if that makes a
> difference too?
The patch alone without the tweaked VM settings doesn't cure the lag - I
think it's better than without the patch (I can actually type this mail
with a large copy running). With the tweaked VM settings too, it's
pretty good - still a little lag, but not enough to really make it
annoying.
Performance is pretty much the same as before (copying an 8GiB file with
15-16MiB/sec - about half the performance of what I get locally on the
file server).
Something that worries me; It seems that 2.4.25 is a lot faster as NFS
client than 2.6.11.6, most notably on writes - see the following
tiobench results (2000 KiB file, tests with 1, 2 and 4 threads) up
against the same NFS server:
2.4.25: (dual athlon MP 1.4GHz, 1G RAM, Intel e1000)
File Block Num Seq Read Rand Read Seq Write Rand Write
Dir Size Size Thr Rate (CPU%) Rate (CPU%) Rate (CPU%) Rate (CPU%)
------- ------ ------- --- ----------- ----------- ----------- -----------
. 2000 4096 1 58.87 54.9% 5.615 5.03% 44.40 44.2% 4.534 8.41%
. 2000 4096 2 56.98 58.3% 6.926 6.64% 41.61 58.0% 4.462 10.8%
. 2000 4096 4 53.90 59.0% 7.764 9.44% 39.85 61.5% 4.256 10.8%
2.6.11.6: (dual PIII 1GHz, 2G RAM, Intel e1000)
File Block Num Seq Read Rand Read Seq Write Rand Write
Dir Size Size Thr Rate (CPU%) Rate (CPU%) Rate (CPU%) Rate (CPU%)
------- ------ ------- --- ----------- ----------- ----------- -----------
. 2000 4096 1 38.34 18.8% 19.61 6.77% 22.53 23.4% 6.947 15.6%
. 2000 4096 2 52.82 29.0% 24.42 9.37% 24.20 27.0% 7.755 16.7%
. 2000 4096 4 62.48 34.8% 33.65 17.0% 24.73 27.6% 8.027 15.4%
44MiB/sec for 2.4 versus 22MiB/sec for 2.6 - any suggestions as to how
this could be improved?
(note; the write performance doesn't change notably with VM tuning nor
with the one-liner change that Trond suggested)
--
/ jakob
next prev parent reply other threads:[~2005-04-09 21:36 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-04-06 16:01 bdflush/rpciod high CPU utilization, profile does not make sense Jakob Oestergaard
2005-04-06 21:28 ` Trond Myklebust
2005-04-07 15:28 ` Jakob Oestergaard
2005-04-06 23:19 ` Greg Banks
2005-04-07 15:38 ` Jakob Oestergaard
2005-04-07 16:01 ` Greg Banks
2005-04-07 16:17 ` Trond Myklebust
2005-04-09 21:35 ` Jakob Oestergaard [this message]
2005-04-09 21:52 ` Trond Myklebust
2005-04-11 7:48 ` Jakob Oestergaard
2005-04-11 12:35 ` Trond Myklebust
2005-04-11 13:47 ` Jakob Oestergaard
2005-04-11 14:35 ` Trond Myklebust
2005-04-11 14:41 ` Jakob Oestergaard
2005-04-11 15:21 ` Trond Myklebust
2005-04-11 15:42 ` Jakob Oestergaard
2005-04-12 1:03 ` Greg Banks
2005-04-12 9:28 ` Jakob Oestergaard
2005-04-19 19:45 ` Jakob Oestergaard
2005-04-19 22:46 ` Trond Myklebust
2005-04-20 13:57 ` Jakob Oestergaard
2005-04-24 7:15 ` Jakob Oestergaard
2005-04-25 3:09 ` Trond Myklebust
2005-04-25 13:50 ` Jakob Oestergaard
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=20050409213549.GW347@unthought.net \
--to=jakob@unthought.net \
--cc=gnb@sgi.com \
--cc=linux-kernel@vger.kernel.org \
--cc=trond.myklebust@fys.uio.no \
/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.