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
