All of lore.kernel.org
 help / color / mirror / Atom feed
From: Steven Pratt <slpratt@austin.ibm.com>
To: linux-btrfs <linux-btrfs@vger.kernel.org>
Subject: More random write performance data
Date: Wed, 08 Apr 2009 16:38:17 -0500	[thread overview]
Message-ID: <49DD1949.1060503@austin.ibm.com> (raw)

Given the anomalies we were seeing on random write workloads, I decided 
to simplify the test and do single threaded odirect random write.  This 
should eliminate the locking issue as well as any pdflush bursty 
behavior.  What I got was not quite what I expected.

The most interesting graph is probably #12,  DM write throughput.  We 
see a baseline of ~7MB/sec with spikes every 30 seconds.  I assume the 
spike are meta data related as the io is being done from user space at a 
steady constant rate.  The really odd thing is that for the entire 
almost 2 hour duration, the amplitude of the spike continues to climb, 
meaning the amount of meta data need to be flushed to disk is ever 
increasing.

http://btrfs.boxacle.net/repository/raid/longrun/btrfs-longrun-1thread/btrfs1.ffsb.random_writes__threads_0001.09-04-08_13.05.54/analysis/iostat-processed.001/chart.html

Looking at graph #8 DM IO/sec, we see that there is even a pattern 
within the pattern of spikes.  It # of IOs in each spike appears to 
change at each interval and repeats over a set of 7, 30 second intervals.

Also, we see that we average 12MB/sec of data written out, for 5MB/sec 
of benchmark throughput.

I have queued up a run without checksums and cow to see how much this 
overhead is reduced.

Steve


             reply	other threads:[~2009-04-08 21:38 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-04-08 21:38 Steven Pratt [this message]
2009-04-08 23:09 ` More random write performance data Chris Mason
2009-04-09 21:41   ` Steven Pratt
2009-04-09 22:21     ` Chris Mason

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=49DD1949.1060503@austin.ibm.com \
    --to=slpratt@austin.ibm.com \
    --cc=linux-btrfs@vger.kernel.org \
    /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.