From: | Henrik <henke(at)mac(dot)se> |
---|---|
To: | Greg Smith <gsmith(at)gregsmith(dot)com> |
Cc: | pgsql-performance(at)postgresql(dot)org |
Subject: | Re: Filesystem benchmarking for pg 8.3.3 server |
Date: | 2008-08-10 19:40:30 |
Message-ID: | 0E80D962-22F4-4669-B09F-E1E44449BF76@mac.se |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
9 aug 2008 kl. 00.47 skrev Greg Smith:
> On Fri, 8 Aug 2008, Henrik wrote:
>
>> It feels like there is something fishy going on. Maybe the RAID 10
>> implementation on the PERC/6e is crap?
>
> 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). Since all non-battery backed caches need to
> get turned off for reliable database use, you might want to double-
> check that on the controller that's driving the SATA disks.
Lucky for my I have BBU on all my controllers cards and I'm also not
using the SATA drives for database. That is why I bought the SAS
drives :) Just got confused when the SATA RAID 5 was sooo much faster
than the SAS RAID10, even random writes. But I should have realized
that SAS is only faster if the number of drives are equal :)
Thanks for the input!
Cheers,
Henke
>
>
> --
> * Greg Smith gsmith(at)gregsmith(dot)com http://www.gregsmith.com
> Baltimore, MD
>
> --
> Sent via pgsql-performance mailing list (pgsql-performance(at)postgresql(dot)org
> )
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-performance
From | Date | Subject | |
---|---|---|---|
Next Message | Sabin Coanda | 2008-08-11 06:53:07 | Re: long transaction |
Previous Message | Scott Carey | 2008-08-10 03:25:07 | Re: why query plan for the inner SELECT of WHERE x IN is wrong, but when run the inner query alone is OK? |