Re: Vacuum/Analyze no se esta ejecutando correctamente

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 <mailto: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 <mailto: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_activitywhere 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
>