Re: Amazon High I/O instances

Поиск
Список
Период
Сортировка
От Sébastien Lorion
Тема Re: Amazon High I/O instances
Дата
Msg-id CAGa5y0Psx==wGM_1jSkq2KTZfswmaWbu_-NH7CCp9Og5QEgGjw@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Amazon High I/O instances  (Sébastien Lorion <sl@thestrangefactory.com>)
Ответы Re: Amazon High I/O instances  (Sébastien Lorion <sl@thestrangefactory.com>)
Список pgsql-general
Is dedicating 2 drives for WAL too much ? Since my whole raid is comprised of SSD drives, should I just put it in the main pool ?

Sébastien

On Wed, Sep 12, 2012 at 8:28 PM, Sébastien Lorion <sl@thestrangefactory.com> wrote:
Ok, make sense .. I will update that as well and report back. Thank you for your advice.

Sébastien


On Wed, Sep 12, 2012 at 8:04 PM, John R Pierce <pierce@hogranch.com> wrote:
On 09/12/12 4:49 PM, Sébastien Lorion wrote:
You set shared_buffers way below what is suggested in Greg Smith book (25% or more of RAM) .. what is the rationale behind that rule of thumb ? Other values are more or less what I set, though I could lower the effective_cache_size and vfs.zfs.arc_max and see how it goes.

I think those 25% rules were typically created when ram was no more than 4-8GB.

for our highly transactional workload, at least, too large of a shared_buffers seems to slow us down, perhaps due to higher overhead of managing that many 8k buffers.    I've heard other read-mostly workloads, such as data warehousing, can take advantage of larger buffer counts.




--
john r pierce                            N 37, W 122
santa cruz ca                         mid-left coast




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


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

Предыдущее
От: Sébastien Lorion
Дата:
Сообщение: Re: Amazon High I/O instances
Следующее
От: Edson Richter
Дата:
Сообщение: Re: Compressed binary field