Re: Large shared_buffer stalls WAS: proposal: Set effective_cache_size to greater of .conf value, shared_buffers

Поиск
Список
Период
Сортировка
От Merlin Moncure
Тема Re: Large shared_buffer stalls WAS: proposal: Set effective_cache_size to greater of .conf value, shared_buffers
Дата
Msg-id CAHyXU0yj0ajEfHL1gro9WhWjhRODc8KC7frAZVN9gZof3uNtWg@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Large shared_buffer stalls WAS: proposal: Set effective_cache_size to greater of .conf value, shared_buffers  (Josh Berkus <josh@agliodbs.com>)
Список pgsql-hackers
On Fri, Sep 13, 2013 at 4:15 PM, Josh Berkus <josh@agliodbs.com> wrote:
> On 09/13/2013 01:58 PM, Merlin Moncure wrote:
>> ok, points similar:
>> *) master/slave config (two slaves for me)
>> *) 'big' server 256GB mem, 32 core
>> *) 80% approx. (perhaps more)
>> *) some spacial searching (but not very much)
>> *) OLTP
>> *) presentation of load, although in my case it did resolve anywhere
>> from 30 secs to half hour
>> *) aside from the spike, 100% healthy
>>
>> points different
>> *) application side pooling: 96 app servers, max 5 connections each
>> (aside: are you using transaction mode pgbouncer?)
>
> Yes

Given that, I would be curious to see what dropping connection pool
down to somewhere between 32-64 connections would do.  This is a
band-aid obviously since not everyone can or wants to run pgbouncer.
But this first thing that pops into my mind in these situations is
that it might alleviate the symptoms.

merlin



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

Предыдущее
От: Josh Berkus
Дата:
Сообщение: Re: Large shared_buffer stalls WAS: proposal: Set effective_cache_size to greater of .conf value, shared_buffers
Следующее
От: Kevin Grittner
Дата:
Сообщение: Re: record identical operator