On Wed, Jul 14, 2010 at 6:57 PM, Scott Carey <sc...@richrelevance.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.noo...@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-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-ow...@postgresql.org > >> [mailto:pgsql-performance-ow...@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.gritt...@wicourts.gov<mailto:kevin.gritt...@wicourts.gov>> > >> wrote: > >>> > >>> Ryan Wexler<r...@iridiumsuite.com<mailto:r...@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 > > > -- > Sent via pgsql-performance mailing list (pgsql-performance@postgresql.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
