Merlin Moncure wrote:
> 2009/11/13 Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>:
>> Laszlo Nagy wrote:
>>> * I need at least 32GB disk space. So DRAM based SSD is not a real
>>> option. I would have to buy 8x4GB memory, costs a fortune. And
>>> then it would still not have redundancy.
>> At 32GB database size, I'd seriously consider just buying a server with
>> a regular hard drive or a small RAID array for redundancy, and stuffing
>> 16 or 32 GB of RAM into it to ensure everything is cached. That's tried
>> and tested technology.
>
> 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.
> *) your data is important
Huh? The data is safely on the hard disk in case of a crash. The RAM is
just for caching.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
