Re: memory question

From: Dave Crooke <dcrooke(at)gmail(dot)com>
To: Scott Marlowe <scott(dot)marlowe(at)gmail(dot)com>
Cc: "Campbell, Lance" <lance(at)illinois(dot)edu>, pgsql-performance(at)postgresql(dot)org
Subject: Re: memory question
Date: 2010-03-25 06:28:24
Message-ID: ca24673e1003242328k447b39a0oa107f53c564657d0@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

What Scott said ... seconded, all of it.

I'm running one 500GB database on a 64-bit, 8GB VMware virtual machine, with
2 vcores, PG 8.3.9 with shared_buffers set to 2GB, and it works great.
However, it's a modest workload, most of the database is archival for data
mining, and the "working set" for routine OLTP is pretty modest and easily
fits in the 2GB, and it's back-ended on to a pretty decent EMC Clariion
FibreChannel array. Not the typical case.

For physical x86 servers, brand name (e.g. Kingston) ECC memory is down to
$25 per GB in 4GB DIMMs, and $36 per GB in 8GB DIMMs .... dollars to
doughnuts you have a server somewhere with 2GB or 4GB parts that can be
pulled and replaced with double the density, et voila, an extra 16GB of RAM
for about $500.

Lots and lots of RAM is absolutely, positively a no-brainer when trying to
make a DB go fast. If for no other reason than people get all starry eyed at
GHz numbers, almost all computers tend to be CPU heavy and RAM light in
their factory configs. I build a new little server for the house every 3-5
years, using desktop parts, and give it a mid-life upgrade with bigger
drives and doubling the RAM density.

Big banks running huge Oracle OLTP setups use the strategy of essentially
keeping the whole thing in RAM .... HP shifts a lot of Superdome's maxed out
with 2TB of RAM into this market - and that RAM costs a lot more than $25 a
gig ;-)

Cheers
Dave

In response to

Browse pgsql-performance by date

  From Date Subject
Next Message Matthew Wakeling 2010-03-25 10:35:28 Re: memory question
Previous Message Robert Haas 2010-03-25 02:16:59 Re: Forcing index scan on query produces 16x faster