Re: performance on new linux box

From: Scott Marlowe <scott(dot)marlowe(at)gmail(dot)com>
To: Scott Carey <scott(at)richrelevance(dot)com>
Cc: Ben Chobot <bench(at)silentmedia(dot)com>, Craig James <craig_james(at)emolecules(dot)com>, "Timothy(dot)Noonan(at)emc(dot)com" <Timothy(dot)Noonan(at)emc(dot)com>, "pgsql-performance(at)postgresql(dot)org" <pgsql-performance(at)postgresql(dot)org>
Subject: Re: performance on new linux box
Date: 2010-07-16 01:22:58
Message-ID: AANLkTimf9SQ_zZX5E-au35ZUEEwow6TmSc9x3NQx90fn@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

On Thu, Jul 15, 2010 at 10:30 AM, Scott Carey <scott(at)richrelevance(dot)com> wrote:
>
> On Jul 14, 2010, at 7:50 PM, Ben Chobot wrote:
>
>> On Jul 14, 2010, at 6:57 PM, Scott Carey wrote:
>>
>>> But none of this explains why a 4-disk raid 10 is slower than a 1 disk system.  If there is no write-back caching on the RAID, it should still be similar to the one disk setup.
>>
>> Many raid controllers are smart enough to always turn off write caching on the drives, and also disable the feature on their own buffer without a BBU. Add a BBU, and the cache on the controller starts getting used, but *not* the cache on the drives.
>
> This does not make sense.

Basically, you can have cheap, fast and dangerous (drive with write
cache enabled, which responds positively to fsync even when it hasn't
actually fsynced the data. You can have cheap, slow and safe with a
drive that has a cache but since it'll be fsyncing it all the the time
the write cache won't actually get used, or fast, expensive, and safe,
which is what a BBU RAID card gets by saying the data is fsynced when
it's actually just in cache, but a safe cache that won't get lost on
power down.

I don't find it that complicated.

In response to

Responses

Browse pgsql-performance by date

  From Date Subject
Next Message Scott Carey 2010-07-16 03:16:10 Re: performance on new linux box
Previous Message Tom Lane 2010-07-16 00:24:46 Re: Question of using COPY on a table with triggers