|From:||Kevin Brown <kevin(at)sysexperts(dot)com>|
|Subject:||Re: How to improve db performance with $7K?|
|Views:||Raw Message | Whole Thread | Download mbox | Resend email|
Tom Lane wrote:
> Kevin Brown <kevin(at)sysexperts(dot)com> writes:
> > In the case of pure random reads, you'll end up having to wait an
> > average of half of a rotation before beginning the read.
> You're assuming the conclusion. The above is true if the disk is handed
> one request at a time by a kernel that doesn't have any low-level timing
> information. If there are multiple random requests on the same track,
> the drive has an opportunity to do better than that --- if it's got all
> the requests in hand.
True, but see below. Actually, I suspect what matters is if they're
on the same cylinder (which may be what you're talking about here).
And in the above, I was assuming randomly distributed single-sector
reads. In that situation, we can't generically know what the
probability that more than one will appear on the same cylinder
without knowing something about the drive geometry.
That said, most modern drives have tens of thousands of cylinders (the
Seagate ST380011a, an 80 gigabyte drive, has 94,600 tracks per inch
according to its datasheet), but much, much smaller queue lengths
(tens of entries, hundreds at most, I'd expect. Hard data on this
would be appreciated). For purely random reads, the probability that
two or more requests in the queue happen to be in the same cylinder is
going to be quite small.
Kevin Brown kevin(at)sysexperts(dot)com
|Next Message||Kevin Brown||2005-04-16 00:58:25||Re: How to improve db performance with $7K?|
|Previous Message||Ron Mayer||2005-04-16 00:10:45||Re: Spend 7K *WHERE*? WAS Intel SRCS16 SATA raid? and How|