On Tue, 27 Jan 2009, M. Edward (Ed) Borasky wrote:
> david@lang.hm 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