Software de uso que lo que hace que una gran base de datos PostgreSQL (hay una mesa con un millón de filas en ella) y los desarrolladores dice que debería VACUUMy ANALYZEperiódicamente. Pero la base de datos PostgreSQL predeterminada está autovacuumactivada.
¿Debo aspirar / analizar en absoluto? ¿Cuales son los beneficios? ¿Cuál es la diferencia entre aspiradora automática y manual?
Por ejemplo, en Pgadmin3, tengo esto:
Respuestas:
Estoy de acuerdo con ETL en que no hay una respuesta corta. El tamaño no es lo único que importa: ejecutamos Bases de datos OLTP PostgreSQL bastante grandes (con algunas tablas> 100,000,000 filas) bajo una carga pesada y actualmente confiamos solo en el vacío automático.
Sin embargo, dos cosas me parecen importantes:
Parece haber un consenso, que el vacío automático nunca debe apagarse, a menos que tenga una carga de trabajo muy bien definida en su base de datos y sepa exactamente lo que está haciendo. Pero, naturalmente, podrías hacer más VACUUMy / o ANALYZEcarreras.
Antes de considerar VACUUMejecuciones adicionales , verificaría cómo se mantiene el vacío automático. Puede verificar si alguna tabla está más allá del umbral de vacío automático consultando pg_stat_user_tablesy pg_class. Publiqué dicha consulta en otro hilo, que podría ser de interés: Aggressive Autovacuum en PostgreSQL .
Desafortunadamente, no es tan fácil (es decir, no es posible en este momento) hacer una verificación similar para los umbrales de autoanálisis. Sin embargo, el análisis automático se activa mucho antes del vacío automático de forma predeterminada y es mucho más barato. Entonces, básicamente, si su base de datos puede mantenerse al día con el vacío automático, probablemente también estará bien con el análisis automático. También se pueden consultar las últimas fechas de autoanálisis pg_stat_user_tables.
Algunas partes de la (más excelente) documentación de PostgreSQL, que encontré útiles:
Autovacuum debería cubrirlo, a menos que haya configurado mal algo. Otras respuestas ya cubren eso.
Sin embargo, hay un caso claramente definido para manual VACUUM (y más importante: manual ANALYZE): tablas temporales , no son consideradas por el demonio de vacío automático. Cito el manual CREATE TABLEaquí :
El demonio de vacío automático no puede acceder y, por lo tanto, no puede aspirar o analizar tablas temporales. Por esta razón, se deben realizar operaciones de vacío y análisis apropiadas mediante comandos SQL de sesión. Por ejemplo, si una tabla temporal se va a utilizar en consultas complejas, es aconsejable ejecutarla
ANALYZEen la tabla temporal después de que se complete.
No hay una respuesta breve para eso, ya que depende de muchos factores. ¿El sistema es lento? ¿La aspiradora automática toca realmente esta mesa? etc.
Aquí hay algunos buenos enlaces sobre este tema:
Tomar una decisión clara requiere una comprensión de la base de datos y más detalles sobre lo que está sucediendo.
No creo que necesite aspirar manualmente, a menos que comience a ver una degradación del rendimiento. Sin embargo, recomendaría encarecidamente revisar la configuración de vacío y autovacío y ajustarla a sus necesidades.
Para ver su configuración actual, ejecute esta consulta:
SELECT *
FROM pg_settings
WHERE name LIKE '%vacuum%'La mayoría de los campos se explican por sí mismos, pero aquí hay documentación sobre ellos: https://www.postgresql.org/docs/current/static/runtime-config-autovacuum.html
Yo diría que su objetivo debería ser configurar el vacío automático para limpiar la basura de manera consistente, pero no ejecutar el vacío automático constantemente
Las configuraciones más importantes son:
El umbral ayuda a evitar que el proceso de limpieza se active con demasiada frecuencia para tablas pequeñas.
La configuración predeterminada funciona bien, a menos que tenga tablas muy grandes. En pocas palabras, si tiene una mesa que ocupa 100 GB, acumulará 20 GB de basura, antes de que se active el vacío automático. Por lo tanto, generalmente recomiendo establecer un factor de escala bajo. Qué tan bajo debes determinar por ti mismo. Yo uso 0.05 en mi proyecto actual
Los umbrales también se pueden aumentar. Muchas aplicaciones tienen un par de tablas, que se actualizan con frecuencia y 50 tuplas no es tanto. Aumentar eso a 1000 no debería conducir a ningún problema, pero por supuesto, debe considerar su propio caso
También puede ajustar el vacío automático y tener diferentes configuraciones para algunas de sus tablas
ALTER TABLE your_table SET (autovacuum_vacuum_scale_factor = 0.05);Si configura scale_factor y umbrales, debería estar bien. También puede aumentar autovacuum_vacuum_cost_limit, que por defecto es igual a vacuum_cost_limit, que se establece en 200. Esta es una característica muy importante del vacío, que no le permite consumir todos los recursos y permite que su aplicación opere con datos incluso durante el proceso de vacío. , pero el valor predeterminado es demasiado bajo. Aumentarlo a 1000 no debería generar demoras significativas, pero permitirá que el proceso de vacío finalice mucho más rápido
Por supuesto, también puede ejecutar el vacío manualmente. En el caso más simple, puede tener un trabajo cron simple, que hará una limpieza completa todas las noches, cuando no se accede con frecuencia a su base de datos
¡Espero que ayude!