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