Un poco de cuidado y preparación de su implementación de PostgreSQL contribuye en gran medida a garantizar el rendimiento, evitar descubrimientos desagradables y establecer una previsibilidad segura. Aquí hay 7 cosas que debe vigilar.
Inflación de mesa
PostgreSQL implementa transacciones usando una técnica llamada MVCC. MVCC es demasiado largo e involucra un tema para discutir en detalle, pero hay tres cosas que debes saberlo:
- Eliminar una fila solo la marca como "invisible" para futuras transacciones.
- Actualizar una fila crea una nueva versión de la fila. La versión anterior se marca como invisible para futuras transacciones y la nueva versión se marca como visible.
- Periódicamente, alguien debe mirar todas las transacciones que se están ejecutando actualmente y decir:OK, la transacción más antigua aquí es la #42, por lo que cada versión de fila que es invisible para la #42 se puede eliminar físicamente sin dañar la consistencia de los datos.
Así es como funciona MVCC (esencialmente), y la implicación es que las actualizaciones se aumente la superficie de almacenamiento de su base de datos física y las eliminaciones no lo harán reducirlo. MVCC suena como una forma perezosa de hacer las cosas, pero es popular porque proporciona consistencia y rendimiento.
Las versiones de fila obsoletas y no deseadas en una tabla se denominan hinchar (o muertos ). El proceso que puede eliminar la hinchazón se llama vacío . PostgreSQL tiene un proceso de vacío activado automáticamente con umbrales ajustables llamado autovacuum y, por supuesto, el comando VACUUM.
En general, la sobrecarga también puede ralentizar las consultas debido a mapas de visibilidad inexactos y E/S de disco desperdiciadas.
Debido a esto, regularmente debería:
- supervisar la cantidad de bloat en una base de datos
- pasar la aspiradora regularmente
- supervise si el vacío se ejecuta regularmente para todas las mesas
Hay algunas consultas SQL para proporcionar estimaciones de aumento por tabla. La herramienta de código abierto pgmetrics proporciona estimaciones de hinchamiento, así como los últimos tiempos de ejecución de vacío manual y automático.
Inflación del índice
Los índices también pueden hincharse. Aunque la estructura interna de los índices es opaca para el usuario de SQL y varía según el tipo de índice (BTree, hash, GIN, GIST, etc.), la idea general sigue siendo que cuando se eliminan las filas a las que hace referencia el índice, el espacio ocupado por la información relacionada dentro del índice solo se elimina lógicamente y no se devuelve al sistema de archivos. El espacio borrado lógicamente puede ser reutilizado por el índice más adelante.
Hay dos formas de hacer que Postgres reduzca el tamaño físico de un índice:
- la versión COMPLETA del comando VACÍO
- REINDEXAR
La expansión del índice debe ser monitoreada, para que al menos esté al tanto de la cantidad de espacio que queda sin usar. En las tablas con una alta rotación de filas, no es raro configurar trabajos de reconstrucción de índice regulares.
El aumento del índice también se puede obtener mediante las mismas consultas que antes, y también a través de pgmetrics.
Transacciones de larga duración
Las transacciones deben ser lo más cortas posible, especialmente en un sistema MVCC.
Imagine que una transacción comenzó ayer y hubo una ejecución de vacío justo después de eso. Ahora, mientras esta transacción esté abierta, más vacíos son inútiles, ya que, por definición, nuestra transacción necesitará ver todas las filas de todas las tablas tal como estaban cuando nuestra transacción comenzó ayer. Incluso si nuestra transacción es de solo lectura, este sigue siendo el caso.
Como resultado, las transacciones de ejecución prolongada crean una hinchazón. También se aferran a los recursos del sistema, mantienen bloqueos no liberados y aumentan las posibilidades de interbloqueos.
La mejor manera de estar atento a las transacciones de larga duración es configurar una alerta para la cantidad de transacciones que se han estado ejecutando durante más de un período determinado. Puede obtener esto desde la vista de estadísticas pg_stat_activity , así:
-- number of transactions that have been open for
-- more than 1 hour
SELECT count(*) FROM pg_stat_activity WHERE xact_start < now()-'1 hour'::interval;Retraso de replicación
Cuando se utiliza la replicación de transmisión para replicar todos los cambios desde un servidor PostgreSQL primario a un modo de espera en caliente (también conocido como réplica de lectura), generalmente hay un ligero retraso entre el momento en que ocurren las actualizaciones de fila en el servidor principal y cuando los cambios son visibles para las aplicaciones conectadas al modo de espera. .
Sin embargo, hay casos en los que este retraso puede aumentar:
- el sistema de reserva no puede recibir ni aplicar los cambios del principal lo suficientemente rápido como para mantenerse al día, generalmente debido a una carga alta o falta de aprovisionamiento
- una red o un disco degradados
- conflictos de consulta
Un modo de espera con un retraso de replicación alto o, peor aún, en aumento, puede dar lugar a consultas en el modo de espera que devuelve datos obsoletos y a un modo de espera que no es apto para la conmutación por error.
Si tiene una configuración de replicación de transmisión, es muy importante monitorear los retrasos de replicación entre cada par primario-en espera, y querrá configurar alertas para verificar si los retrasos de replicación exceden un minuto, o cualquier umbral que tenga sentido para su configuración.
Esta publicación tiene mucho más sobre cómo medir y monitorear el retraso de la replicación desde los extremos primario y en espera.
Ranuras de replicación inactivas
El uso de ranuras de replicación, introducido en PostgreSQL 9.4, hace que la replicación de transmisión sea más sólida y eficiente. Esencialmente, el standby informa sobre el progreso de la replicación al principal, que almacena esta información en la "ranura de replicación".
Debido a esto, el primario ahora sabe en todo momento qué tan atrás está el standby. Esto permite que el primario retenga una acumulación suficiente de archivos WAL (que son necesarios para reanudar la replicación) cuando el standby se desconecta. Por lo tanto, cuando vuelve el modo de espera, incluso después de mucho tiempo, el principal aún puede garantizar que la replicación se puede reanudar.
Antes de las ranuras de replicación, el principal puede limpiar los archivos WAL antiguos, ya que no tenía forma de saber si los recursos de reserva los necesitaban o no. Si se elimina un archivo WAL que necesita astandby, no hay forma de reanudar la replicación; tiene que volver a configurarse desde cero.
Sin embargo, el comportamiento del primario de retener archivos WAL indefinidamente conduce a otro problema. Si se retiró un modo de espera y no se eliminó la ranura de replicación asociada, los archivos WAL se conservarán para siempre. Los archivos WAL retenidos por este motivo no están sujetos a los límites establecidos por max_wal_size y otras opciones de configuración.
Esta situación persistirá hasta que los archivos WAL consuman todo el espacio del disco, sin siquiera una advertencia en los archivos de registro de PostgreSQL.
No hace falta decir que las ranuras de replicación inactivas deben tratarse cuando se detectan. Encuentre sus ranuras de replicación inactivas usando:
SELECT slot_name FROM pg_replication_slots WHERE NOT active;Analizar estado
ANALYZE se ejecuta en tablas para recopilar y actualizar información estadística sobre el contenido de la tabla. El planificador de consultas utiliza esta información para preparar el plan de ejecución para cada consulta SQL. Las estadísticas actualizadas sobre el contenido de la tabla dan como resultado un mejor plan de ejecución, lo que a su vez da como resultado una consulta más rápida.
El daemon autovacuum generalmente ejecuta ANALYZE después de VACUUM. Sin embargo, esto puede no ser lo suficientemente frecuente para ANALIZAR. Si la distribución de los datos en una tabla cambia con frecuencia, debería ejecutar ANALYZE con más frecuencia.
Por lo general, ANALYZE se comporta bastante bien:solo necesita bloqueos de lectura, no consume demasiados recursos y se completa en un tiempo razonable. Es seguro equivocarse al ejecutarlo la mayoría de las veces.
Estar atento a las tablas que no han sido ANALIZADAS por un tiempo es una buena idea. Averigüe la última vez que sus tablas fueron (auto-) analizadas con la consulta:
SELECT schemaname || '.' || relname, last_analyze, last_autoanalyze
FROM pg_stat_user_tables;Uso de recursos
Supervisar la carga de la CPU, la memoria y el uso del disco contribuye en gran medida a garantizar que tendrá suficiente capacidad disponible para satisfacer las crecientes necesidades de las aplicaciones que utilizan su base de datos.
PostgreSQL genera un proceso para manejar una conexión. Si bien esta puede no ser la arquitectura más escalable en la actualidad, contribuye mucho en el frente de la estabilidad. También hace que el promedio de carga del sistema operativo sea más significativo. Como por lo general, los cuadros de PostgreSQL solo ejecutan PostgreSQL, un promedio de carga de, digamos, 3 generalmente significa que hay 3 conexiones esperando que los núcleos de la CPU estén disponibles para que puedan programarse. Supervisar su promedio de carga máxima durante un día o una semana típicos puede dar una estimación de qué tan aprovisionado en exceso o insuficiente está su caja en el frente de la CPU.
La memoria y el espacio libre en disco son, por supuesto, cosas estándar para monitorear. Más conexiones y transacciones de mayor duración exigen más memoria. Y mientras supervisa el espacio libre en el disco, recuerde realizar un seguimiento por espacio de tablas.
