Re: Auto-vacuum is not running in 9.1.12

Поиск
Список
Период
Сортировка
От Alvaro Herrera
Тема Re: Auto-vacuum is not running in 9.1.12
Дата
Msg-id 20150610144906.GY133018@postgresql.org
обсуждение исходный текст
Ответ на Auto-vacuum is not running in 9.1.12  (Prakash Itnal <prakash074@gmail.com>)
Ответы Re: Auto-vacuum is not running in 9.1.12
Список 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 по дате отправления:

Предыдущее
От: Fujii Masao
Дата:
Сообщение: Re: reaper should restart archiver even on standby
Следующее
От: Jan Wieck
Дата:
Сообщение: Re: s_lock() seems too aggressive for machines with many sockets