Re: Vacuum/Analyze no se esta ejecutando correctamente

Despues de mas de 19 horas seguidas, estos procesos se siguen ejecutando,
sin reflejar ningun resultado en la base de datos.

pid | query | age

-------+----------------------------------------------------+-------------------------

6279 | autovacuum: VACUUM ANALYZE pg_catalog.pg_class | 25 days
18:37:41.526188

32520 | VACUUM (ANALYZE); |
19:27:39.746022

20776 | vacuum ANALYZE verbose; |
19:11:23.328425

Los he tratado de detener si resultado alguno.

postgres=# select pg_terminate_backend(32520);

pg_terminate_backend

----------------------

t

(1 row)

pid | query |
age

-------+-------------------------------------------------------------+-------------------------

6279 | autovacuum: VACUUM ANALYZE pg_catalog.pg_class | 25
days 18:41:12.710997

32520 | VACUUM (ANALYZE); |
19:31:10.930831

20776 | vacuum ANALYZE verbose;

Hace 25 dias que el proceso 6279 ha estado corriendo interrumpidamente, si
no mal recuerdo en un momento que reinicie el servicio de postgres ese
proceso se detuvo forzosamente y cuando el servicio reanudo entonces el
proceso se empezo a ajecutar interrumpidamente desde ese entonces.

Autovacuum se esta ejecutando sin problema, pero no puedo ejecutar un
vacuum manual.

Ejecute un vacuum manual a una tabla specificamente, pero el relfrozendid
no se reinicio tampoco.

postgres=# vacuum ANALYZE pg_shdescription;

VACUUM

postgres=# vacuum pg_shdescription;

VACUUM

table_name | age | percentage_transaction_ids_used |
table_size

-----------------------+-----------+---------------------------------+------------

pg_shdescription | 747265306 | 35.584 | 48 kB

No recuerdo si lo dije anteriormente, pero el mismo cron job ha estado
ejecutandoce por casi 4 meses en mi servidor de pre-production sin ningun
tipo de problema.

Algo que deben saber, que este es el servidor que hace unas semanas que
migre hace 9.6 del servidor que tenia la tabala pg_databases corructa en
9.3, y ahora que me pongo a pensar desde que lo hice el analyze y vacuum
manual de alguna manera u otra no han funcionado correctamente, pero
autovacuum reinicio todo los XID para evitar un wraparound en us momento.

Este un comportamiento que no habia visto antes en postgres, asi que
agradecere cualquier tipo de ayuda, sugerencia o documentacion que me guie
a una solucion.

Carlos

On Sun, Jun 9, 2019 at 1:59 AM Carlos T. Groero Carmona <ctonetg(at)gmail(dot)com>
wrote:

> Hola lista,
>
> Esyou utilizando la version 9.6 de postgres, y hal algo que me tiene un
> poco confundifo con utovacuum/analyze.
>
> Primero desde que migre a este nueva version, se ha estado ejecuatando un
> proceso autovacuum analyze por mas de 24 dias, he tratado de eliminarlo
> ejecutando terminate_backend() y no se detiene, tambien trate con kill pid
> y tampoco se detiene.
>
> Lo otro que me esta sucediendo un poco raro es que se esta demorando
> demaisado un siemple vacuum analyze en base de datos con menos de 1GB de
> tamano, ademas lo ejecute en postgres database, y nunca se reinicio el xid.
>
> postgres=# vacuum ANALYZE ;
>
> VACUUM
>
> postgres=# SELECT
>
> datname,
>
> max(age(datfrozenxid)),
>
> round(max(age(datfrozenxid)) / 2100000000.0 * 100.0, 3) AS
> percentage_transaction_ids_used
>
> FROM pg_database
>
> group by datname
>
> order by 2 desc;
>
> datname | max | percentage_transaction_ids_used
>
> -------------------------+-----------+---------------------------------
>
> sami_production | 874194263 | 41.628
>
> locations | 799037901 | 38.049
>
> ofx_production | 799037901 | 38.049
>
> locations_backup | 799037901 | 38.049
>
> internal_p2p_production | 799035844 | 38.049
>
> template1 | 799035844 | 38.049
>
> semi_temp | 799035709 | 38.049
>
> auth_db | 749061558 | 35.670
>
> template0 | 749045061 | 35.669
>
> postgres | 730570342 | 34.789
>
> (10 rows)
>
>
> el xid in postgres deberia estar por debajo del 10% despues de ejecutar
> vacuum en esa base de datos.
>
>
>
>
> postgres=# select pg_terminate_backend(20776);
>
> pg_terminate_backend
>
> ----------------------
>
> t
>
> (1 row)
>
>
> postgres=# select pid, query, age(now(), xact_start) from pg_stat_activity
> where upper(query) like upper('vacuu%') and state = 'active' or
> upper(query) like upper('auto%') order by 3 desc;
>
> pid | query |
> age
>
>
> -------+------------------------------------------------------+-------------------------
>
> 6279 | autovacuum: VACUUM ANALYZE pg_catalog.pg_class | 24 days
> 23:43:14.417379
>
> 26680 | autovacuum: VACUUM public.transactions_w |
> 02:43:22.432889
>
> 28142 | autovacuum: VACUUM public.featureusagereportusers |
> 01:06:05.995937
>
> 1682 | autovacuum: VACUUM public.sessionusagereportusers |
> 00:58:54.605847
>
> 30236 | autovacuum: VACUUM ANALYZE public.sessions |
> 00:43:47.847795
>
> 32520 | VACUUM (ANALYZE); |
> 00:33:12.637213
>
> 20776 | vacuum ANALYZE verbose; |
> 00:16:56.219616
>
> 10801 | autovacuum: VACUUM ANALYZE pg_catalog.pg_attribute |
> 00:16:54.8015
>
> 24212 | autovacuum: VACUUM public.transactions_f |
> 00:16:27.303903
>
> 1533 | autovacuum: VACUUM public.mobileusermo . |
> 00:10:12.41268
>
> 27837 | autovacuum: VACUUM public.batchhistories_fieldpoint |
> 00:00:53.361894
>
> 30151 | autovacuum: VACUUM public.featureusagereportyearlies |
> 00:00:23.799779
>
> (12 rows)
>
>
> El proceso 32520 es ejecutado por un cronjob que tengo planificado correr
> cada domingo a la 1am
>
> y el proceso 20776 lo ejecute para probar si mi sospecha de que vacuum no
> se esta ejecutando correctamente y no quisiera usar la palabra corrupta,
> apenas cabo de migrar a la version 9.6 porque tuve pg_databa estaba
> corructa en la version 9.3
>
>
> sobre autovacuum solo tengo 10 workers y el cost_limit es 1200.
>
>
> Alguna idea de lo que esta pasando y como podria detener esos processos
> que sin afectar el cluster.
>
>
> es una option kill -9 vacuum_pid?
>
>
> Una vez mas gracias por la ayuda,
>
> Carlos
>