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

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. 

Unless that one-disk setup turned off fsync() or was configured with synchronous_commit off.  Even low end laptop
drivesdon't lie these days about a cache flush or sync() -- OS's/file systems can, and some SSD's do. 

If loss of a transaction during a power failure is OK, then just turn synchronous_commit off and get the performance
back. The discussion about transaction rate being limited by the disks is related to that, and its not necessary _IF_
itsok to lose a transaction if the power fails.  For most applications, losing a transaction or two in a power failure
isfine.  Obviously, its not with financial transactions or other such work. 


On Jul 8, 2010, at 2:42 PM, Craig James wrote:

> On 7/8/10 2:18 PM, Timothy.Noonan@emc.com wrote:
>> How does the linux machine know that there is a BBU installed and to
>> change its behavior or change the behavior of Postgres? I am
>> experiencing performance issues, not with searching but more with IO.
>
> It doesn't.  It trusts the disk controller.  Linux says, "Flush your cache" and the controller says, "OK, it's
flushed." In the case of a BBU controller, the controller can say that almost instantly because it's got the data in a
battery-backedmemory that will survive even if the power goes out.  In the case of a non-BBU controller (RAID or
non-RAID),the controller has to actually wait for the head to move to the right spot, then wait for the disk to spin
aroundto the right sector, then write the data.  Only then can it say, "OK, it's flushed." 
>
> So to Linux, it just appears to be a disk that's exceptionally fast at flushing its buffers.
>
> Craig
>
>>
>> -----Original Message-----
>> From: pgsql-performance-owner@postgresql.org
>> [mailto:pgsql-performance-owner@postgresql.org] On Behalf Of Craig James
>> Sent: Thursday, July 08, 2010 4:02 PM
>> To: pgsql-performance@postgresql.org
>> Subject: Re: [PERFORM] performance on new linux box
>>
>> On 7/8/10 12:47 PM, Ryan Wexler wrote:
>>>
>>>
>>> On Thu, Jul 8, 2010 at 12:46 PM, Kevin Grittner
>>> <Kevin.Grittner@wicourts.gov<mailto:Kevin.Grittner@wicourts.gov>>
>> wrote:
>>>
>>>     Ryan Wexler<ryan@iridiumsuite.com<mailto:ryan@iridiumsuite.com>>
>>>     wrote:
>>>
>>>> One thing I don't understand is why BBU will result in a huge
>>>> performance gain.  I thought BBU was all about power failures?
>>>
>>>     Well, it makes it safe for the controller to consider the write
>>>     complete as soon as it hits the RAM cache, rather than waiting for
>>>     persistence to the disk itself.  It can then schedule the writes
>> in
>>>     a manner which is efficient based on the physical medium.
>>>
>>>     Something like this was probably happening on your non-server
>>>     machines, but without BBU it was not actually safe.  Server class
>>>     machines tend to be more conservative about not losing your data,
>>>     but without a RAID controller with BBU cache, that slows writes
>> down
>>>     to the speed of the rotating disks.
>>>
>>>     -Kevin
>>>
>>> Thanks for the explanations that makes things clearer.  It still
>> amazes
>>> me that it would account for a 5x change in IO.
>>
>> It's not exactly a 5x change in I/O, rather it's a 5x change in
>> *transactions*.  Without a BBU Postgres has to wait for each transaction
>> to by physically written to the disk, which at 7200 RPM (or 10K or 15K)
>> means a few hundred per second.  Most of the time Postgres is just
>> sitting there waiting for the disk to say, "OK, I did it."  With BBU,
>> once the RAID card has the data, it's virtually guaranteed it will get
>> to the disk even if the power fails, so the RAID controller says, "OK, I
>> did it" even though the data is still in the controller's cache and not
>> actually on the disk.
>>
>> It means there's no tight relationship between the disk's rotational
>> speed and your transaction rate.
>>
>> Craig
>>
>
>
> --
> Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-performance