From: | Ryan Wexler <ryan(at)iridiumsuite(dot)com> |
---|---|
To: | Kevin Grittner <Kevin(dot)Grittner(at)wicourts(dot)gov> |
Cc: | Jochen Erwied <jochen(at)pgsql-performance(dot)erwied(dot)eu>, pgsql-performance(at)postgresql(dot)org |
Subject: | Re: performance on new linux box |
Date: | 2010-07-08 19:47:52 |
Message-ID: | AANLkTino2ep4VyJDA9PVV6FObxHnBlLX3O9z8q19PzfN@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
On Thu, Jul 8, 2010 at 12:46 PM, Kevin Grittner <Kevin(dot)Grittner(at)wicourts(dot)gov
> wrote:
> Ryan Wexler <ryan(at)iridiumsuite(dot)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.
From | Date | Subject | |
---|---|---|---|
Next Message | Kevin Grittner | 2010-07-08 19:50:27 | Re: [Slony1-general] WAL partition overloaded--by autovacuum? |
Previous Message | Kevin Grittner | 2010-07-08 19:46:34 | Re: performance on new linux box |