On Sat, Nov 14, 2009 at 6:17 AM, Heikki Linnakangas <heikki.linnakangas@xxxxxxxxxxxxxxxx> wrote: >> lots of ram doesn't help you if: >> *) your database gets written to a lot and you have high performance >> requirements > > When all the (hot) data is cached, all writes are sequential writes to > the WAL, with the occasional flushing of the data pages at checkpoint. > The sequential write bandwidth of SSDs and HDDs is roughly the same. > > I presume the fsync latency is a lot higher with HDDs, so if you're > running a lot of small write transactions, and don't want to risk losing > any recently committed transactions by setting synchronous_commit=off, > the usual solution is to get a RAID controller with a battery-backed up > cache. With a BBU cache, the fsync latency should be in the same > ballpark as with SDDs. BBU raid controllers might only give better burst performance. If you are writing data randomly all over the volume, the cache will overflow and performance will degrade. Raid controllers degrade in different fashions, at least one (perc 5) halted ALL access to the volume and spun out the cache (a bug, IMO). >> *) your data is important > > Huh? The data is safely on the hard disk in case of a crash. The RAM is > just for caching. I was alluding to not being able to lose any transactions... in this case you can only run fsync, synchronously. You are then bound by the capabilities of the volume to write, ram only buffers reads. merlin -- Sent via pgsql-performance mailing list (pgsql-performance@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
