On Sat, Nov 14, 2009 at 6:17 AM, Heikki Linnakangas
<heikki.linnakangas@enterprisedb.com> 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