Re: [GENERAL] autovacuum holds exclusive lock on table preventing itfrom to be updated - Mailing list pgsql-general

From Scott Marlowe
Subject Re: [GENERAL] autovacuum holds exclusive lock on table preventing itfrom to be updated
Date
Msg-id CAOR=d=1PORgwq9u3ndamThBERhMZCm+G-XHai9-gB3ZJTTsGJQ@mail.gmail.com
Whole thread Raw
In response to Re: [GENERAL] autovacuum holds exclusive lock on table preventing itfrom to be updated  (Dmitry O Litvintsev <litvinse@fnal.gov>)
List pgsql-general
On Mon, Jun 19, 2017 at 1:53 PM, Dmitry O Litvintsev <litvinse@fnal.gov> wrote:
> yes, we had to restart database 4 days ago (and vacuum has resumed on start).
> I checked the log files and discovered that autovacuum on this table takes
>
>         pages: 0 removed, 14072307 remain
>         tuples: 43524292 removed, 395006545 remain
>         buffer usage: -1493114028 hits, 107664973 misses, 30263658 dirtied
>         avg read rate: 1.604 MB/s, avg write rate: 0.451 MB/s
>         system usage: CPU 2055.81s/17710.94u sec elapsed 524356.57 sec
>
> 6 days. So it is perpetually being autovacuumed (which I assumed to be a good thing)
>
> Table has 400M entries, 115 GB.
>
> I will try your suggestions in the test environment.
>
> Thank you,
> Dmitry

Once you get this sorted, look into using the checkpostgresql.pl
script and a monitoring solution like zabbix or nagios to monitor
things like transactions until wraparound etc so you don't wind up
back here again. Best of luck in. Note that if you drop the vacuum
delay to 0ms the vacuum will probably complete in a few hours tops.


pgsql-general by date:

Previous
From: Israel Brewster
Date:
Subject: Re: [GENERAL] sub-select with multiple records, columns
Next
From: Bruce Momjian
Date:
Subject: Re: [GENERAL] effective_io_concurrency increasing