From: | "Benjamin Krajmalnik" <kraj(at)servoyant(dot)com> |
---|---|
To: | "Greg Smith" <greg(at)2ndquadrant(dot)com> |
Cc: | <pgsql-performance(at)postgresql(dot)org> |
Subject: | Re: Configuration for a new server. |
Date: | 2011-02-02 17:46:06 |
Message-ID: | F4E6A2751A2823418A21D4A160B689887B0E51@fletch.stackdump.local |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
>See how buffers_backend is much larger than buffers_clean, even though maxwritten_clean is low? That means the background writer isn't running often enough to keep up with cleaning things, even though >it does a lot of work when it does kick in. In your situation I'd normally do a first pass by cutting bgwriter_lru_maxpages to 1/4 of what it is now, cut bgwriter_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 baseline to compare against. These numbers aren't very useful with a single value, >but once you get two of them with timestamps you 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
From | Date | Subject | |
---|---|---|---|
Next Message | Mladen Gogala | 2011-02-02 18:11:33 | Re: [HACKERS] Slow count(*) again... |
Previous Message | Greg Smith | 2011-02-02 17:24:26 | Re: About pg_stat_activity |