Re: performance on new linux box

On Wed, Jul 14, 2010 at 6:57 PM, Scott Carey <scott(at)richrelevance(dot)com>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.
>
> Unless that one-disk setup turned off fsync() or was configured with
> synchronous_commit off. Even low end laptop drives don'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_ its ok to lose a transaction if the power fails. For most
> applications, losing a transaction or two in a power failure is fine.
> 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(dot)Noonan(at)emc(dot)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-backed memory 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 around to 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(at)postgresql(dot)org
> >> [mailto:pgsql-performance-owner(at)postgresql(dot)org] On Behalf Of Craig
> James
> >> Sent: Thursday, July 08, 2010 4:02 PM
> >> To: pgsql-performance(at)postgresql(dot)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(dot)Grittner(at)wicourts(dot)gov<mailto:Kevin(dot)Grittner(at)wicourts(dot)gov>>
> >> wrote:
> >>>
> >>> Ryan Wexler<ryan(at)iridiumsuite(dot)com<mailto: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.
> >>
> >> 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(at)postgresql(dot)org)
> > To make changes to your subscription:
> > http://www.postgresql.org/mailpref/pgsql-performance
>
>
> --
> Sent via pgsql-performance mailing list (pgsql-performance(at)postgresql(dot)org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-performance
>

Something was clearly wrong with my former raid card. Frankly, I am not
sure if it was configuration or simply hardware failure. The server is
hosted so I only had so much access. But the card was swapped out with a
new one and now performance is quite good. I am just trying to tune the new
card now.
thanks for all the input