Re: Awful RAID5 random read performance

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Goswin von Brederlow wrote:
John Robinson <john.robinson@xxxxxxxxxxxxxxxx> writes:

On 03/06/2009 19:38, Bill Davidsen wrote:
John Robinson wrote:
On 02/06/2009 20:47, Keld Jørn Simonsen wrote:
[...]
In your case, using 3 disks, raid5 should give about 210 % of the
nominal
single disk speed for big file reads, and maybe 180 % for big file
writes. raid10,f2 should give about 290 % for big file reads and 140%
for big file writes. Random reads should be about the same for raid5 and
raid10,f2 - raid10,f2 maybe 15 % faster, while random writes should be
mediocre for raid5, and good for raid10,f2.
I'd be interested in reading about where you got these figures from
and/or the rationale behind them; I'd have guessed differently...
For small values of N, 10,f2 generally comes quite close to N*Sr,
where N is # of disks and Sr is single drive read speed. This is
assuming fiarly large reads and adequate stripe buffer
space. Obviously for larger values of N that saturates something
else in the system, like the bus, before N gets too large. I don't
generally see more than (N/2-1)*Sw for write, at least for large
writes. I came up with those numbers based on testing 3-4-5 drive
arrays which do large file transfers. If you want to read more than
large file speed into them, feel free.

With far copies reading is like reading raid0 and writing is like
raid0 but writing twice with a seek between each. So (N/2) and (N/2-a
bit) are the theoretical maximums and raid10 comes damn close to those.

Actually it was the RAID-5 figures I'd have guessed differently. I'd
expect ~290% (rather than 210%) for big 3-disc RAID-5 reads, and ~140%
(rather than "mediocre") for random small writes. But of course I
haven't tested.

That kind of depends on the chunk size I think.

Say you have a raid 5 with chunk size << size of 1 track. Then on each
disk you read 2 chunks, skip a chunk, read 2 chunks, skip a chunk. But
skipping a chunk means waiting for the disk to rotate over it. That
takes as long as reading it. You shouldn't even get 210% speed.

Only if chunk size >> size of 1 track could you seek over a
chunk. And you have to hope that by the time you have seeked the start
of the next chunk hasn't rotated past the head yet.

Anyone know what the size of a track is on modern disks? How many
sectors/track do they have?

It varies to keep the bpi constant, so there are more sectors on outer tracks and transfer rate is higher. raid10 can use outer tracks in more cases (with the "far" layout) and thus delivers a higher transfer rate. Or so the theory goes, in practice raid10 *does* give a higher transfer rate, so the above is theory to explain the observed facts.

--
Bill Davidsen <davidsen@xxxxxxx>
 Even purely technical things can appear to be magic, if the documentation is
obscure enough. For example, PulseAudio is configured by dancing naked around a
fire at midnight, shaking a rattle with one hand and a LISP manual with the
other, while reciting the GNU manifesto in hexadecimal. The documentation fails
to note that you must circle the fire counter-clockwise in the southern
hemisphere.



--
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Linux RAID Wiki]     [ATA RAID]     [Linux SCSI Target Infrastructure]     [Linux Block]     [Linux IDE]     [Linux SCSI]     [Linux Hams]     [Device Mapper]     [Device Mapper Cryptographics]     [Kernel]     [Linux Admin]     [Linux Net]     [GFS]     [RPM]     [git]     [Yosemite Forum]


  Powered by Linux