From: Andreas Dilger <adilger@turbolabs.com>
To: Robert Cohen <robert.cohen@anu.edu.au>
Cc: linux-kernel@vger.kernel.org
Subject: Re: [Bench] New benchmark showing fileserver problem in 2.4.12
Date: Wed, 17 Oct 2001 09:47:03 -0600 [thread overview]
Message-ID: <20011017094703.E7859@turbolinux.com> (raw)
In-Reply-To: <3BCD8269.B4E003E5@anu.edu.au>
In-Reply-To: <3BCD8269.B4E003E5@anu.edu.au>
On Oct 17, 2001 23:06 +1000, Robert Cohen wrote:
> Factor 1: the performance problems only occur when you are rewriting an
> existing file in place. That is writing to an existing file which is
> opened without O_TRUNC. Equivalently, if you have written a file and
> then seek'ed back to the beginning and started writing again.
>
> Evidence: in the report I posted yesterday, the test I was using
> involved 5 clients rewriting 30 Meg files on a 128 Meg machine. The
> symptom was that after about 10 seconds, the throughput as shown by
> vmstat "bo" drops sharply and we start getting reads occuring as shown
> by the "bi" figure.
Just a guess - if you are getting reads that are about the same as writes,
then it would indicate that the code is doing "read-modify-write" for the
existing file data rather than just "write". This would be caused by not
writing only full-sized aligned blocks to the files.
As to why this is happening only over the network - it may be that you are
are unable to send an even multiple of the blocksize over the network (MTU)
and this is causing fragmented writes. Try using a smaller block size like
4k or so to see if it makes a difference.
Another possibility is that with 8k chunks you are needing order-1
allocations to receive the data and this is causing a lot of searching for
buffers to free.
Cheers, Andreas
--
Andreas Dilger \ "If a man ate a pound of pasta and a pound of antipasto,
\ would they cancel out, leaving him still hungry?"
http://www-mddsp.enel.ucalgary.ca/People/adilger/ -- Dogbert
next prev parent reply other threads:[~2001-10-17 15:47 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-10-17 13:06 [Bench] New benchmark showing fileserver problem in 2.4.12 Robert Cohen
2001-10-17 14:12 ` Marcelo Tosatti
2001-10-17 15:12 ` M. Edward Borasky
2001-10-17 15:18 ` John Stoffel
2001-10-17 15:47 ` Andreas Dilger [this message]
2001-10-17 16:44 ` Linus Torvalds
2001-10-18 2:01 ` Leo Mauro
2001-10-18 8:30 ` James Sutherland
2001-10-18 21:36 ` Roger Larsson
2001-10-19 2:53 ` George Greer
2001-10-19 6:08 ` Roger Larsson
[not found] ` <200110171644.f9HGinZ17717@penguin.transmeta.com>
2001-10-18 4:51 ` Robert Cohen
-- strict thread matches above, loose matches on Subject: below --
2001-10-16 9:07 Robert Cohen
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=20011017094703.E7859@turbolinux.com \
--to=adilger@turbolabs.com \
--cc=linux-kernel@vger.kernel.org \
--cc=robert.cohen@anu.edu.au \
/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