Recuperando espacio de una base de datos Postgres

En esos momentos de duda siempre me pregunto: ¿Qué Haría Jesús?

https://www.postgresql.org/docs/9.2/static/logfile-maintenance.html

VittokoX dijo:

En esos momentos de duda siempre me pregunto: ¿Qué Haría Jesús?

https://www.postgresql.org/docs/9.2/static/logfile-maintenance.html

Haz clic para expandir...

Creo que no me expliqué bien...

Lo que crece no es el log de postgres. Crece la tabla en que el aplicativo guarda los logs de eventos.

Zuljin dijo:

Creo que no me expliqué bien...

Lo que crece no es el log de postgres. Crece la tabla en que el aplicativo guarda los logs de eventos.

Haz clic para expandir...

eso suena a como que el aplicativo estuviera generando un exceso de registros (posiblemente por algún error en una tarea )
en la documentación del aplicativo no dice si se puede limpiar dicha tabla de registros y dejar, por decir algo, los últimos 60 días ?

Enviado desde mi MSM8916 for arm64 mediante Tapatalk

yo tengo la base del firewall en postgres (la unica que tengo es un sophos utm 9 creo que con una version recortada de opensuse) y cuando se infla tiramos este comando
sudo /etc/init.d/postgresql rebuild
sudo /etc/init.d/postgresql92 rebuild (me soplaron que la nueva versión puede usar este)
y vuala, una lipo en 10 segundos.

Buenas,
No cachaba lo del rebuild, voy a mirar el script ese.
estoy usando
vacuum full analyse;
en un cron en una bd productiva por el mismo tema, y funciona bien.
recupera harto espacio de los datos eliminados pero que no se reflejan fisicamente, no necesitas hacer nada mas, aunque a veces se demora algo en el proceso..

Subo el tema, por si el vikingo @unreal4u tiene más datos.

https://lob.com/blog/supercharge-your-postgresql-performance

Aprovechando que tengo las aplicaciones abajo voy a hacer un vacuum full.


A partir de la versión 9.x el vacuum incluye reindexación.

Espero que en los últimos 12 meses hayas descubierto cómo resolver esto.
En todo caso no es necesario ni eficiente hacer VACUUM FULL ANALYZE, es lento y caro, y sólo vale la pena cuando te echas algo, haces un insert gigante y matas el backend en la mitad, particionas antes de PG 11 y se te olvida ponerle contraint exclusion, y en fin, todas esas cosas terribles.

VACUUM debiera bastar para lo que necesitas (necesitabas?) y de paso debieras configurar PG con un parámetro para el setting AUTOVACUUM que como su nombre indica es para no tener que ejecutar el VACUUM en locomoción colectiva.

Amenadiel dijo:

Espero que en los últimos 12 meses hayas descubierto cómo resolver esto.
En todo caso no es necesario ni eficiente hacer VACUUM FULL ANALYZE, es lento y caro, y sólo vale la pena cuando te echas algo, haces un insert gigante y matas el backend en la mitad, particionas antes de PG 11 y se te olvida ponerle contraint exclusion, y en fin, todas esas cosas terribles.

VACUUM debiera bastar para lo que necesitas (necesitabas?) y de paso debieras configurar PG con un parámetro para el setting AUTOVACUUM que como su nombre indica es para no tener que ejecutar el VACUUM en locomoción colectiva.

Haz clic para expandir...

Era (es) la base de datos repositorio de un sistema de respaldo. El log lo guarda en una tabla, la cual era leída por la aplicación para mostrarte los eventyos. Esa tabla culiada creció más que la cresta por lo que la aplicación se iba a la superchucha cuando se requería leer eventos.
La necesidad era truncarle toda la historia excepto los últimos meses pero igual quedó jetona, por lo que la mano era vacuumearla una vez y después dejarla en auto.
Gracias por el up XD

Después de un insert o la eliminación de muchos registros intermedios la tabla siempre va a quedar fragmentada. El VACUUM es como defragmentar (opcionalmente ordenando) y por mucho que tenga autovacuum el motor de PG no tiene cómo saber si ya terminaste de borrar cosas o si vas a seguir revisando qué más podar, de manera que no se pone a hacer defragmentación luego de cada poda masiva (salvo en un truncate, pero no estoy seguro) y lo más sano es hacerlo uno.

Me tinca que para tu caso de uso te serviría particionar y mover los logs a tablas históricas. Por ejemplo:

- tabla_logs
- logs_201906
- logs_201907
- logs_mes_actual

cuando llega el cambio de mes creas una tabla logs_201908 y le insertas todo lo que hay en el mes actual. Luego le haces un VACUUM (después de inserciones masivas y eliminación de registros intermedios, siempre es bueno) y después los índices si es que los necesitas. La tabla de mes_actual se vacía y luego se aplica VACUUM. Con esto el sistema mantiene tablas de tamaño razonable, y cada tabla histórica es super compacta .

Todo lo anterior no es estrictamente necesario pero trabajando con una cola histórica menor es más rápido de vacumizar?, vaacuumar? vacunar? y puedes consultar directo una tabla mensual dado que lo requieras.

(funciona mejor si es Postgres 11, dado que añadieron un sistema de particiones alternativo pero mejor al actual de tablas hijas y constraint exclusion)

Ah guena. Igual voy a ver si la nueva versión del software de respaldo permite la última versión de Postgres para que no me vuelva a pasar lo mismo.