Re: [PERFORMANCE] Buying hardware

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



david@xxxxxxx wrote:
> 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?

I'm not sure there are any rules of thumb / guidelines for that. My
experience has been that doing no disk I/O except writing logs to disk,
creating and updating rows is an unrealistic expectation, even for
"small" databases. The cost is prohibitive, for one thing. And for
capacity planning, what's probably more important is whether the service
level agreements are being met, not whether you're meeting them purely
in RAM or by re-reading data from disk sometimes.

I think it's "easy", however, to solve the inverse problem. Borrow a
huge-memory server from your vendor, put your small database up on it,
run benchmarks and gradually reduce the amount of memory available until
the performance becomes unacceptable.

The tools exist to measure memory allocations while the benchmarks are
running. If you get enough data points (about five for the simplest
models) you can build a model that you could then "invert" to go the
other way. -- take a database size and figure out how much more RAM was
needed to meet the SLAs.

You don't necessarily have to reboot to reduce available memory -- there
are ways you can tie up memory without consuming processor or disk time
to do so. But you would need to "poison" the caches between runs, and
restart PostgreSQL if you're modifying its memory allocations.

-- 
M. Edward (Ed) Borasky

I've never met a happy clam. In fact, most of them were pretty steamed.

-- 
Sent via pgsql-performance mailing list (pgsql-performance@xxxxxxxxxxxxxx)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance

[Postgresql General]     [Postgresql PHP]     [PHP Users]     [PHP Home]     [PHP on Windows]     [Kernel Newbies]     [PHP Classes]     [PHP Books]     [PHP Databases]     [Yosemite]

  Powered by Linux