Re: Large shared_buffer stalls WAS: proposal: Set effective_cache_size to greater of .conf value, shared_buffers - Mailing list pgsql-hackers

From Merlin Moncure
Subject Re: Large shared_buffer stalls WAS: proposal: Set effective_cache_size to greater of .conf value, shared_buffers
Date
Msg-id CAHyXU0yj0ajEfHL1gro9WhWjhRODc8KC7frAZVN9gZof3uNtWg@mail.gmail.com
Whole thread Raw
In response to Re: Large shared_buffer stalls WAS: proposal: Set effective_cache_size to greater of .conf value, shared_buffers  (Josh Berkus <josh@agliodbs.com>)
List 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 by date:

Previous
From: Josh Berkus
Date:
Subject: Re: Large shared_buffer stalls WAS: proposal: Set effective_cache_size to greater of .conf value, shared_buffers
Next
From: Kevin Grittner
Date:
Subject: Re: record identical operator