Re: Industry db benchmark result on recent 2.6 kernels

[Nick Piggin]

David Lang wrote:

> On Sat, 2 Apr 2005, Andreas Dilger wrote:
>
> > > given that this would let you get the same storage with about 1200 
> > > fewer
> > > drives (with corresponding savings in raid controllers, fiberchannel
> > > controllers and rack frames) it would be interesting to know how 
> > > close it
> > > would be (for a lot of people the savings, which probably are within
> > > spitting distance of $1M could be work the decrease in performance)
> >
> >
> > For benchmarks like these, the issue isn't the storage capacity, but
> > rather the ability to have lots of heads seeking concurrently to
> > access the many database tables.  At one large site I used to work at,
> > the database ran on hundreds of 1, 2, and 4GB disks long after they
> > could be replaced by many fewer, larger disks...
>
>
> I can understand this to a point, but it seems to me that after you 
> get beyond some point you stop gaining from this (simply becouse you 
> run out of bandwidth to keep all the heads busy). I would have guessed 
> that this happened somewhere in the hundreds of drives rather then the 
> thousands, so going from 1500x73G to 400x300G (even if this drops you 
> from 15Krpm to 10Krpm) would still saturate the interface bandwidth 
> before the drives

But in this case probably not - Ken increases IO capacity until the CPUs 
become saturated.
So there probably isn't a very large margin for error, you might need 
2000 of the slower
SATA disks to achieve a similar IOPS capacity.


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