Re: autovac hitting too many tables at once
От | Greg Williamson |
---|---|
Тема | Re: autovac hitting too many tables at once |
Дата | |
Msg-id | 1340394089.27581.YahooMailNeo@web46103.mail.sp1.yahoo.com обсуждение исходный текст |
Ответ на | Re: autovac hitting too many tables at once ("Kevin Grittner" <Kevin.Grittner@wicourts.gov>) |
Ответы |
Re: autovac hitting too many tables at once
|
Список | pgsql-admin |
Kevin -- <...> >> a) quickly relieve the immediate pain > > Set autovacuum_cost_limit to a smaller value. (Change the > postgresql.conf file and do a reload.) I would start by cutting the > current value in half. > Thanks -- would not have known how to start. But for now, in observance of your idea on XID wraparound, I am letting everything run (this is actually a low point in regular traffic for this site and I am not seeing firect proof that autovac is in fact doing anything out of the ordinary). >> and >> >> b) prevent such issues in the future (other than going to manual >> vacuuming on a schedule). > > If it is suddenly doing this on lots of big tables at once, it seems > somewhat likely that you've hit the transaction wraparound > protection threshold. Because the vacuum necessary for this can be > painful, and they tend to come at the worst possible time (the more > your workload looks like a really heavy OLTP workload at any given > moment, the higher the probability that this is about to happen), I > always follow a bulk load (like from restoring pg_dump output) with > a VACUUM FREEZE ANALYZE. > > You might also want to consider running off-hours vacuums to > supplement autovacuum. Upgrading to a more recent version of > PostgreSQL is likely to help some, too. > Duly noted. Thanks! Greg
В списке pgsql-admin по дате отправления: