Re: Bloated tables

Hola Diego, como andas hermano? ha pasado un tiempo desde que hablamos por
ultima vez...

Mira quizas te confundi cuando explique en el pasado como estaban las cosas
y porque no podia usar autovacuum muy agresivo.

Actualmente mi configuration de autovacuum esta genial, tengo autovacuum
corriendo y de una manera bastante agresiva, la menor cantidad de tuplas
muertas y autovacuum empieza a correr es una bestia.
por eso es que puedo hacer vacuum a toda la base datos en apenas 2 horas y
medias, siguiendo la idea de mas vacuum mas rapido termina.

Creo que las ideas que me distes son geniales acerca de como tratar este
problema, hay algunas que no puedo aplicar por la forma en que
esta estructurado el servidor o la manera en que el negocio funciona, te
explico:

1. No puedo crear or mover indexes a un diferente tablespace ahora mismo
porque es un servidor fisico y tiene todos los racks para discos llenos con
un Volumen Logico RAID10 dedicado a postgres, por lo que pongo donde ponga
los indices estaria usando el IO de ese LVM cierto? y hacerlo por red me
afectaria mas de lo que me ayudaria porque en este LVM tengo espacio.
2. Sobre como eliminar el bloat pues quiero usar vacuum full como dices,
creo que es lo mas simple, el problema estaria en buscar las ventanas
adecuadas para hacerlo porque mi DB es 24/7 y solo tengo un maitenance
windows cada 4 meses, asi que usare ese tiempo, lo unico que me preocupa es
hacerle vacuum full a pg_indexes or pg_tables, creo que
podria bloquearme todo el sistema no crees?

Saludos,
Carlos

On Wed, Apr 8, 2020 at 6:44 AM Diego <mrstephenamell(at)gmail(dot)com> wrote:

> Hola Carlos!
>
> Che, estando en centos 7, ojala sea en 7.7 ;P no seria muy costoso ir
> hasta pg 11 o 12, donde las tareas de vacuum son mucho mas eficientes? un
> pgupgrate con -k y sale en unos minutos.
>
> ahora bien, el tema puntual, supongo que tenes el autovacuum apagado
> directamente... no lo vayas a prender si no queres empezar a tener locks
> por todos lados.
>
> Vas a tener que vacuumear objeto por objeto la primera vez, y setear una
> config no muuy violenta, cosa que puedasseguir trabajando mientras pegas la
> vuelta. yo no iria con otro que no sea vacuum... en lo que hace a indices,
> crea los mismos que tenes concurrently y al finalizar dropea los actuales
> cosa de reemplazarlos por unos en buen estado.
>
> Probablemente te convenga particionar por semana, 53 child al año, cosa de
> poder vacuumear mas simplemente. lo mismo, separar los indices a otro
> tablespace.
>
> en fin, espero darte una idea de lo que yo haria.
> On 7/4/20 17:16, Carlos T. Groero Carmona wrote:
>
> Hola lista,
>
> He estado revisando como se encuentra mi base de datos de production en
> cuanto a bloat, y si bien tengo muchas tablas or encima del 40% me preocupa
> mucho algunas tablas del catalogo de postgres como:
> pg_class
> pg_type
> pg_attribute
> pg_depend
> pg_index
>
> Veamos expecificamente pg_index:
> Real_size: 15 GB
> Extra_size: 15 GB
> Extra_ratio: 99.9%
>
> Note: Estoy usando esta query:
> https://github.com/ioguix/pgsql-bloat-estimation/blob/master/table/table_bloat.sql
>
>
> Por supuesto tambien tengo tablas propias de la aplicacion con saos
> similares:
> tb_audit:
> Real_size: 74 GB
> Extra_size: 66 GB
> Extra_ratio: ~89%
>
> Esta base de datos es OLTP con una forma bastante agresiva de update la
> information en esa tabla y en el pasado autovacuum no podia ser tan
> agresivo como lo es ahora por problemas de hardware, si lo configuraba
> agresivo me usaba todo el IO en el servidor, entonces CPU tambien se
> afectaba y se degradaba el tiempo de respuesta del sistema y se formaba un
> lio.
>
> La forma que encontre de migrar +2TB de un servidor a otro. fue replicar y
> entonces hacer un upfrade de 9.3 a 9.6.
>
> Me fue bastante bien en el proceso pero el problema me traje todo el bloat
> conmigo al parecer.
>
> Desde entonces la configuration de autovacuum cambio al tanto que es
> posible hacer vacuum freeze a todo el servidor (+2.3TB) en menos de 2 horas.
>
> Revisando como resolver este problema solo encontre unas pocas formas:
> 1. vacuum full: todos sabemos que pasara durante este proceso,
> 2. pg_repack: it could cause replication issue and start a new replication
> could cause about 2 days with not DR or be a single point of failure
> 3. pgcompacttable: como dije anteriormente, en la forma que actualizamos
> nuestra informacion es muy agresiva, por lo que no creo sea suficientemente
> fuerte para encargarse de toda la information que tenmos.
>
> Estoy pensando en hacer vaccum full a aquellas tablas mas affectadas con
> bloat, ya sean de postgres or internas durante algun maintenace windows
> (solo puedo usar uno cada 4 meses por unas pocas horas), pero no seria una
> solucion a mi problema actual.
>
> Ya atovacuum y vacuum han sido reforzados, algun consejo basado en
> experiencias anteriores de como manejar esta situation?
>
> Creo qu elo dije anteriormente, pero por si acaso.
> Estoy usando postgres 9.6, centOs 7.x, en un servidor fisico dedicado.
>
> Saludos,
> Carlos
>
>