Tengo el mismo problema con el vacuum. Antes usaba la versión 9.4 y todo
bien. Ahora uso la 9.6 y tengo problemas.
Saludos, jose
El dom., 9 jun. 2019 a las 22:07, Carlos T. Groero Carmona (<
cton...@gmail.com>) escribió:
>
> 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 <cton...@gmail.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
>>
>
