Re: sequential disk read speed
Date: Wed, 27 Aug 2008 21:32:56 -0700 (PDT)
Message-ID: <40d67c8b-d516-4721-a52d-20579c2ca9ac_at_r35g2000prm.googlegroups.com>
On Aug 28, 10:47 am, "Brian Selzer" <br..._at_selzer-software.com> wrote:
> "David BL" <davi..._at_iinet.net.au> wrote in message
>
> news:b3a7632f-de18-46e8-8ce3-3c5aaf83d4b9_at_a3g2000prm.googlegroups.com...
>
>
>
>
>
> > On Aug 24, 12:39 pm, "Brian Selzer" <br..._at_selzer-software.com> wrote:
>
> >> If you have a 100GB database and you put it on single
> >> 100GB disk drive, your best average seek time is the average seek time of
> >> the disk drive, but if you put the database on four 100GB disk drives,
> >> the
> >> the best average seek time will only be a fraction of the seek time of
> >> the
> >> single disk. Suppose that the full-stroke seek time on the 100GB disk is
> >> 7ms and the track-to-track seek time is 1ms. Well, with four disks,
> >> instead
> >> of an average 4ms seek time, the individual seek time of each disk is
> >> reduced to roughly 2.5ms
>
> > Is this because less of the disk is actually being used so on a given
> > platter the head doesn't have such a large range of tracks to move
> > over?
>
> Yes. And the bit density is generally greater at the outside of the
> platter, so it generally takes fewer tracks to store the same information
> there as opposed to near the center; consequently, simply dividing the
> difference of the full-stroke seek and the track-to-track seek by four is a
> perhaps overly conservative method of estimation. I want to stress that
> this is not just a hair-brained theory of mine: I've had significant success
> using this mechanism to boost performance. In one application, by
> installing a disk that was seven times the size required and creating a
> partition on the outer edge of the disk, performance improved by over 6000%:
> batch processes that had been taking over 25 hours to complete were
> finishing in under 25 minutes.
How do you explain a 60 fold increase?
> >> , and since there are four disks, the average seek
> >> time for the disk subsystem is reduced to a quarter of that or roughly
> >> .625ms.
>
> > In order for the effective seek time to be reduced to a quarter the
> > seeking must be independent. To achieve that I think the striping
> > would need to be very coarse (eg 512kb or 1Mb).
>
> Drives that support disconnection or some other command queueing mechanism
> are all that is needed for seeking to be independent.
If stripes are somewhat smaller than the DBMS block size, then every drive (in the RAID 0) will be involved in the reading of each and every DBMS block. No matter how you order those reads, each drive needs to read a large amount of scattered data and the head will seek around a lot. If that is the case then the only advantage arises from your previously mentioned reduction in the overall range of tracks over which the data resides on a given platter.
Alternatively if the stripe size is larger then each drive will read a somewhat independent set of the DBMS blocks, and the effective seek time can be reduced assuming the DBMS is able to issue overlapping read requests for the DBMS blocks.
> I think using a coarse stripe is counterproductive. There would be a bigger
> chance that a seek in the middle of the read would be required. Consider:
> if 3.5 stripes fit on a track in one zone of the disk, then on average every
> fourth read would require an additional seek to get the remaining half
> stripe. If on the other hand, 28 stripes fit on a track, then no additional
> seeks would be necessary. Even if it were 28.5 stripes instead of 28, one
> additional seek for every 29 reads is a whole lot better than one for every
> 4.
Firstly, hard-disks are quite good at stepping onto the next track in the manner normally used for very large "contiguous" reads or writes.
The following