Re: Filesystem benchmarking for pg 8.3.3 server

Поиск
Список
Период
Сортировка
От Henrik
Тема Re: Filesystem benchmarking for pg 8.3.3 server
Дата
Msg-id 0E80D962-22F4-4669-B09F-E1E44449BF76@mac.se
обсуждение исходный текст
Ответ на Re: Filesystem benchmarking for pg 8.3.3 server  (Greg Smith <gsmith@gregsmith.com>)
Ответы Re: Filesystem benchmarking for pg 8.3.3 server  (Glyn Astill <glynastill@yahoo.co.uk>)
Re: Filesystem benchmarking for pg 8.3.3 server  (Greg Smith <gsmith@gregsmith.com>)
Список 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@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


В списке pgsql-performance по дате отправления:

Предыдущее
От: "Scott Carey"
Дата:
Сообщение: Re: why query plan for the inner SELECT of WHERE x IN is wrong, but when run the inner query alone is OK?
Следующее
От: "Sabin Coanda"
Дата:
Сообщение: Re: long transaction