From: | Johnny Tan <johnnydtan(at)gmail(dot)com> |
---|---|
To: | Kevin Grittner <kgrittn(at)ymail(dot)com> |
Cc: | "ac(at)hsk(dot)hk" <ac(at)hsk(dot)hk>, Josh Krupka <jkrupka(at)gmail(dot)com>, Alex Kahn <alex(at)paperlesspost(dot)com>, "pgsql-performance(at)postgresql(dot)org" <pgsql-performance(at)postgresql(dot)org> |
Subject: | Re: postgresql.conf recommendations |
Date: | 2013-02-06 19:33:45 |
Message-ID: | CABMVzL0j=quCGWEdHO922kOjzmbqA7CntwMtE6abT=cx+sZaxQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
On Wed, Feb 6, 2013 at 7:49 AM, Kevin Grittner <kgrittn(at)ymail(dot)com> wrote:
> "ac(at)hsk(dot)hk" <ac(at)hsk(dot)hk> wrote:
> > Johnny Tan <johnnydtan(at)gmail(dot)com> wrote:
>
> >>shared_buffers = 48GB# min 128kB
>
> > From the postgresql.conf, I can see that the shared_buffers is
> > set to 48GB which is not small, it would be possible that the
> > large buffer cache could be "dirty", when a checkpoint starts, it
> > would cause a checkpoint I/O spike.
> >
> >
> > I would like to suggest you about using pgtune to get recommended
> > conf for postgresql.
>
> I have seen symptoms like those described which were the result of
> too many dirty pages accumulating inside PostgreSQL shared_buffers.
> It might be something else entirely in this case, but it would at
> least be worth trying a reduced shared_buffers setting combined
> with more aggressive bgwriter settings. I might try something like
> the following changes, as an experiment:
>
> shared_buffers = 8GB
> bgwriter_lru_maxpages = 1000
> bgwriter_lru_multiplier = 4
>
Thanks Kevin. Wouldn't this be controlled by our checkpoint settings,
though?
From | Date | Subject | |
---|---|---|---|
Next Message | Johnny Tan | 2013-02-06 19:45:38 | Re: postgresql.conf recommendations |
Previous Message | David Whittaker | 2013-02-06 19:13:56 | Re: postgresql.conf recommendations |