From: | "Carlos T(dot) Groero Carmona" <ctonetg(at)gmail(dot)com> |
---|---|
To: | Lista PostgreSql <pgsql-es-ayuda(at)postgresql(dot)org> |
Subject: | Bloated tables |
Date: | 2020-04-07 20:16:05 |
Message-ID: | CABh6Tc2VOb5YLM6yn_d+H8hW=n3dA76KTXa7emafZnbVKS+eMA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-es-ayuda |
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
From | Date | Subject | |
---|---|---|---|
Next Message | Moises Silva | 2020-04-08 02:41:20 | Capacitación postgres |
Previous Message | Rafael Valenzuela | 2020-04-03 08:12:15 | Re: Exportaciòn de tablas a CSV |