On Tue, 27 Jan 2009, M. Edward (Ed) Borasky wrote:
david@xxxxxxx wrote:
On Mon, 26 Jan 2009, David Rees wrote:
And yes, the more memory you can squeeze into the machine, the better,
though you'll find that after a certain point, price starts going up
steeply. Of course, if you only have a 15GB database, once you reach
16GB of memory you've pretty much hit the point of diminishing
returns.
actually, you need more memory than that. besides the data itself you
would want memory for several other things, among them:
1. your OS
2. your indexes
3. you per-request memory allocations (for sorting, etc)
this is highly dependant on your workload (type and number of parallel
requests)
4. 'dead' tuples in your table (that will be cleared by a vaccum, but
haven't been yet)
and probably other things as well.
I don't know how large a database will fit in 16G of ram, but I suspect
it's closer to 8G than 15G.
any experts want to throw out a rule-of-thumb here?
There are starting to be some tools built that will show you how RAM is
allocated, now that recent kernels (2.6.25+) do a better job of
accounting for RAM pages. So I would expect the total memory dedicated
to the database functionality to be much closer to 15 GB than 8 GB.
that's not quite the opposite of the statement that I was trying to make.
assuming that you are not running anything else on the system, how much
data can you put on the system and run entirely out of ram.
the database has it's overhead (sort buffers, indexes, per-request
buffers, 'dead tuples', etc) that mean that if you have a database that
an uncompressed dump takes 8G, you need substantially more than 8G of ram
to avoid using the disks (other than to store changes)
how much more is the question. I know it is going to vary from
installation to installation, but is there any guidelines that people can
start with?
David Lang
--
Sent via pgsql-performance mailing list (pgsql-performance@xxxxxxxxxxxxxx)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance
