Re: Configuration for a new server. - Mailing list pgsql-performance

From Benjamin Krajmalnik
Subject Re: Configuration for a new server.
Date
Msg-id F4E6A2751A2823418A21D4A160B689887B0E51@fletch.stackdump.local
Whole thread Raw
In response to Re: Configuration for a new server.  (Greg Smith <greg@2ndquadrant.com>)
Responses Re: Configuration for a new server.
List pgsql-performance

>See how buffers_backend is much larger than buffers_clean, even though maxwritten_clean is low?  That means the
backgroundwriter isn't running often enough to keep up with cleaning things, even though >it does a lot of work when it
doeskick in.  In your situation I'd normally do a first pass by cutting bgwriter_lru_maxpages to 1/4 of what it is now,
cutbgwriter_delay to 1/4 as well (to 50ms), and >then see how the proportions change.  You can probably cut the
multiplier,too, yet still see more pages written by the cleaner. 

>I recommend saving a snapsot of this data with a timestamp, i.e.:

>select now(),* from pg_stat_bgwriter;

>Anytime you make a change to one of the background writer or checkpoint timing parameters.  That way you have a new
baselineto compare against.  These numbers aren't very useful with a single value, >but once you get two of them with
timestampsyou can compute all sorts of fun statistics from the pair. 

So, if I understand correctly, I should strive for a relative increase in buffers_clean to buffers_backend



pgsql-performance by date:

Previous
From: Greg Smith
Date:
Subject: Re: About pg_stat_activity
Next
From: Mladen Gogala
Date:
Subject: Re: [HACKERS] Slow count(*) again...