All of lore.kernel.org
 help / color / mirror / Atom feed
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


  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 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.