Re: performance on new linux box - Mailing list pgsql-performance

From Scott Carey
Subject Re: performance on new linux box
Date
Msg-id 0BC62364-BD19-41E0-A483-677474CD5A5D@richrelevance.com
Whole thread Raw
In response to Re: performance on new linux box  (Ben Chobot <bench@silentmedia.com>)
Responses Re: performance on new linux box
Re: performance on new linux box
List pgsql-performance
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
theRAID, 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
ontheir own buffer without a BBU. Add a BBU, and the cache on the controller starts getting used, but *not* the cache
onthe drives. 

This does not make sense.
Write caching on all hard drives in the last decade are safe because they support a write cache flush command properly.
If the card is "smart" it would issue the drive's write cache flush command to fulfill an fsync() or barrier request
withno BBU. 

>
> Take away the controller, and most OS's by default enable the write cache on the drive. You can turn it off if you
want,but if you know how to do that, then you're probably also the same kind of person that would have purchased a raid
cardwith a BBU. 

Sure, or you can use an OS/File System combination that respects fsync() which will call the drive's write cache flush.
 There are some issues with certain file systems and barriers for file system metadata, but for the WAL log, we're only
dalkingabout fdatasync() equivalency, which most file systems do just fine even with a drive's write cache on. 


pgsql-performance by date:

Previous
From: Patrick Donlin
Date:
Subject: Re: Identical query slower on 8.4 vs 8.3
Next
From: Ben Chobot
Date:
Subject: Re: performance on new linux box