Re: [PERFORMANCE] Buying hardware

Поиск
Список
Период
Сортировка
От M. Edward (Ed) Borasky
Тема Re: [PERFORMANCE] Buying hardware
Дата
Msg-id 497F2641.2030109@cesmail.net
обсуждение исходный текст
Ответ на Re: [PERFORMANCE] Buying hardware  (david@lang.hm)
Список pgsql-performance
david@lang.hm 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.

В списке pgsql-performance по дате отправления:

Предыдущее
От: david@lang.hm
Дата:
Сообщение: Re: [PERFORMANCE] Buying hardware
Следующее
От: Josh Berkus
Дата:
Сообщение: Re: Odd behavior with temp usage logging