On Thu, Dec 03, 2015 at 07:51:28PM -0500, Thor Lancelot Simon wrote:
>
> What strategy are you using to sort inside RAIDframe? This is a property
> of the RAID set; you can see it with raidctl I believe for autoconfigured
> sets.
>
> I wouldn't be terribly surprised to see bad interactions between
> priocscan and RAIDframe's scan or cscan strategies. What about the "fifo"
> strategy?
It has been the fifo queuing method (queue size: 100) since 2010, when I
created the set (based on the NetBSD RAIDframe guide).
> It's important, though, to understand that there are *very* few pure bulk
> read applications in this world (except single-stream video) and very
> few pure bulk write applications except database logs. That means that
> single-stream pure read or write tests are really pretty awful predictors
> of disk performance for real workloads.
I also tried a 5-stream dd test, based on one of your previous mails:
https://mail-index.netbsd.org/netbsd-users/2014/12/01/msg015503.html
All five streams got ~10MB/s each (bs=16k), more or less consistent with
the bonnie++ output.
I should retry that with priocscan.
> The "priocscan" strategy, in particular, limits pure read/pure write
> performance *by design* in order to achieve lower latency under real
> world mixed workloads.
Intuitively, I'd always expect some penalty by any kind of queueing, but
for a simple sequential write, the numbers are just way off. These
disks can sustain 100MB/s seq. reads and I assume it's not much worse
when writing sequentially (unfortunately I can't test that now).. so
35MB/s seems broken and even 55MB/s kind of low.
Attachment:
signature.asc
Description: PGP signature