Re: Auto-vacuum is not running in 9.1.12 - Mailing list pgsql-hackers

From Alvaro Herrera
Subject Re: Auto-vacuum is not running in 9.1.12
Date
Msg-id 20150610144906.GY133018@postgresql.org
Whole thread Raw
In response to Auto-vacuum is not running in 9.1.12  (Prakash Itnal <prakash074@gmail.com>)
Responses Re: Auto-vacuum is not running in 9.1.12  (Prakash Itnal <prakash074@gmail.com>)
List pgsql-hackers
Prakash Itnal wrote:
> Hello,
> 
> Recently we encountered a issue where the disc space is continuously
> increasing towards 100%. Then a manual vacuum freed the disc space. But
> again it is increasing. When digged more it is found that auto-vacuuming
> was not running or it is either stucked/hanged.

Hm, we have seen this on Windows, I think.

Is the "stats collector" process running?  Is it stuck?

If you attach to process 6504 (autovac launcher), what's the backtrace?

> 4) Last run auto-vacuum:
> SELECT now(), schemaname, relname, last_vacuum, last_autovacuum, vacuum_count, autovacuum_count FROM
pg_stat_user_tables;
> 
>               now              | schemaname |    relname    | last_vacuum |        last_autovacuum        |
vacuum_count| autovacuum_count 
 
>
-------------------------------+------------+---------------+-------------+-------------------------------+--------------+------------------
>  2015-06-10 01:03:03.574212+02 | public     | abcd          |             | 2015-04-18 00:52:35.008874+02 |
0 |                2
 
>  2015-06-10 01:03:03.574212+02 | public     | xyz           |             | 2015-05-02 06:01:35.220651+02 |
0 |               20
 
> 
> NOTE: I changed the relname for above two tables due to confidentiality.

Are there dead tuples in tables?  Maybe vacuums are getting executed and
these values are not updated, for instance?

-- 
Álvaro Herrera                http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services



pgsql-hackers by date:

Previous
From: Fujii Masao
Date:
Subject: Re: reaper should restart archiver even on standby
Next
From: Jan Wieck
Date:
Subject: Re: s_lock() seems too aggressive for machines with many sockets