Re: Configuration for a new server.
От | Benjamin Krajmalnik |
---|---|
Тема | Re: Configuration for a new server. |
Дата | |
Msg-id | F4E6A2751A2823418A21D4A160B689887B0E51@fletch.stackdump.local обсуждение исходный текст |
Ответ на | Re: Configuration for a new server. (Greg Smith <greg@2ndquadrant.com>) |
Ответы |
Re: Configuration for a new server.
|
Список | 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 по дате отправления: