Re: Vacuum/Analyze no se esta ejecutando correctamente

Nada. Sigue ejecuntando sin nigun problema. Pero tarda horas y antes lo
hacia en minutos.

Saludos, jose

El mié., 12 jun. 2019 a las 1:40, Horacio Miranda (<hmiranda(at)gmail(dot)com>)
escribió:

> Que te dicen los logs ?
> On 11/06/2019 1:26 AM, José González wrote:
>
> 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 (<
> ctonetg(at)gmail(dot)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 <
>> 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
>>>
>>