From: Steven Pratt <steve@dangyankee.net>
To: linux-btrfs <linux-btrfs@vger.kernel.org>
Subject: Updated performance results
Date: Thu, 23 Jul 2009 13:35:21 -0500 [thread overview]
Message-ID: <4A68AD69.4030803@dangyankee.net> (raw)
I have re-run the raid tests with re-creating the fileset between each
of the random write workloads and performance does now match the
previous newformat results. The bad news is that the huge gain that I
had attributed to the newformat release, does not really exist. All of
the previous results(except for the newformat run) were not re-creating
the fileset, so the gain in performance was due only to having a fresh
set of files, not any code changes.
So, I have done 2 new sets of runs to look into this further. One is a 3
hour run of single threaded random write to the RAID system. I have
compared this to ext3. Performance results are here:
http://btrfs.boxacle.net/repository/raid/longwrite/longwrite/Longrandomwrite.html
and graphing of all the iostat data can be found here:
http://btrfs.boxacle.net/repository/raid/longwrite/summary.html
The iostat graphs for btrfs are interesting for a number of reasons.
First, it takes about 3000 seconds (or 50 minutes) for btrfs to reach
steady state. Second, if you look at write throughput from the device
view vs. the btrfs/application view, we see that for a application
throughput of 21.5MB/sec it requires 63MB/sec of actual disk writes.
That is an overhead of 3 to 1 vs an overhead of ~0 for ext3. Also,
looking at the change in iops vs MB/sec, we see that while btrfs starts
out with reasonable size IOs, it quickly deteriorate to an average IO
size of only 13kb. Remember, the starting file set is only 100GB on a
2.1TB filesystem, and all data is overwrite, and this is single
threaded, so there is no reason this should fragment. It seems like the
allocator is having a problem doing sequential allocations.
Another set of runs I did was to do repetitive 5 minute random write
runs. Results are here:
http://btrfs.boxacle.net/repository/raid/repeat/repeat/repeat.html
This shows the dramatic degredation after just a short time, but I
believe there is a fair amount of overhead in btrfs after newly mounting
the FS (which this test did between each run) so I repeated without
unmounting and remounting and results are here:
http://btrfs.boxacle.net/repository/raid/repeat-nomount/repeat/repeat-nomount.html
These results show a much less dramatic degradation, but btrfs still
degrades by over 40% in just 30 minutes of run time. In fact, it was
still degrading by 10% every 5 minutes when this test ended.
Steve
next reply other threads:[~2009-07-23 18:35 UTC|newest]
Thread overview: 38+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-07-23 18:35 Steven Pratt [this message]
2009-07-23 21:00 ` Updated performance results Chris Mason
2009-07-23 22:04 ` Steven Pratt
2009-07-24 13:24 ` Chris Mason
2009-07-24 14:00 ` Chris Mason
2009-07-24 15:05 ` Steven Pratt
2009-07-28 20:12 ` Steven Pratt
2009-07-28 20:23 ` Chris Mason
2009-07-28 21:10 ` Steven Pratt
2009-08-05 20:35 ` Chris Mason
2009-08-07 7:30 ` debian developer
2009-08-07 13:56 ` Steven Pratt
2009-08-07 13:56 ` Steven Pratt
2009-08-07 23:12 ` Chris Mason
2009-08-31 17:49 ` Steven Pratt
2009-09-11 19:29 ` Chris Mason
2009-09-11 21:35 ` Steven Pratt
2009-09-14 13:51 ` Chris Mason
2009-09-14 17:20 ` Jens Axboe
2009-09-14 21:41 ` Steven Pratt
2009-09-14 23:13 ` Chris Mason
2009-09-16 0:52 ` Chris Mason
2009-09-16 15:15 ` Steven Pratt
2009-09-16 17:57 ` Steven Pratt
2009-09-16 18:07 ` Chris Mason
2009-09-16 18:15 ` Steven Pratt
2009-09-16 18:17 ` Chris Mason
2009-09-16 18:16 ` Steven Pratt
2009-09-16 18:20 ` Chris Mason
2009-09-16 18:37 ` Steven Pratt
2009-09-17 18:32 ` Eric Whitney
2009-09-17 18:39 ` Steven Pratt
2009-09-17 18:52 ` Chris Mason
2009-09-17 20:17 ` Chris Mason
2009-09-17 20:43 ` Chris Mason
2009-09-17 22:04 ` Steven Pratt
2009-09-18 20:14 ` Chris Mason
2009-09-23 15:24 ` Steven Pratt
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=4A68AD69.4030803@dangyankee.net \
--to=steve@dangyankee.net \
--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.