Hi again all,
Just wanted to give you an update.
Talked to Dell tech support and they recommended using write-
through(!) caching in RAID10 configuration. Well, it didn't work and
got even worse performance.
Anyone have an estimated what a RAID10 on 4 15k SAS disks should
generate in random writes?
I'm really keen on trying Scotts suggestion on using the PERC/6 with
mirror sets only and then make the stripe with Linux SW raid.
Thanks for all the input! Much appreciated.
Cheers,
Henke
11 aug 2008 kl. 17.56 skrev Greg Smith:
> On Sun, 10 Aug 2008, Henrik wrote:
>
>>> Normally, when a SATA implementation is running significantly
>>> faster than a SAS one, it's because there's some write cache in
>>> the SATA disks turned on (which they usually are unless you go out
>>> of your way to disable them).
>> Lucky for my I have BBU on all my controllers cards and I'm also
>> not using the SATA drives for database.
>
>> From how you responded I don't think I made myself clear. In
>> addition to
> the cache on the controller itself, each of the disks has its own
> cache, probably 8-32MB in size. Your controllers may have an option
> to enable or disable the caches on the individual disks, which would
> be a separate configuration setting from turning the main controller
> cache on or off. Your results look like what I'd expect if the
> individual disks caches on the SATA drives were on, while those on
> the SAS controller were off (which matches the defaults you'll find
> on some products in both categories). Just something to double-check.
>
> By the way: getting useful results out of iozone is fairly
> difficult if you're unfamiliar with it, there are lots of ways you
> can set that up to run tests that aren't completely fair or that you
> don't run them for long enough to give useful results. I'd suggest
> doing a round of comparisons with bonnie++, which isn't as flexible
> but will usually give fair results without needing to specify any
> parameters. The "seeks" number that comes out of bonnie++ is a
> combined read/write one and would be good for double-checking
> whether the unexpected results you're seeing are independant of the
> benchmark used.
>
> --
> * Greg Smith gsmith@gregsmith.com http://www.gregsmith.com
> Baltimore, MD
>
> --
> Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org
> )
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-performance
