Afinamiento de bases de datos PostgreSQL

Tuning de bases de datos PostgreSQL

PostgreSQL es una base de datos relacional de código abierto que es muy flexible y confiable. Ofrece un conjunto de funcionalidades que no tienen nada que envidiarle a bases de datos de pago, como es el caso de Oracle, DB2 o Informix. Aunque es una base de datos que ha evolucionado incorporando funcionalidades más profesionales, proporciona una gran integridad y rendimiento. Además, se puede implementar en múltiples plataformas, incluida una versión liviana para sitios web y teléfonos inteligentes.

Debido a que PostgreSQL se puede implementar de diferentes maneras, viene listo para usar con solo algunos ajustes básicos de rendimiento basados ​​en el entorno en el que se estará implementando. Por lo tanto, es importante que una vez que implemente la base de datos se asegure de afinarla según su caso de uso para obtener el mejor rendimiento posible.

¿Qué es el Afinamiento de Bases de Datos PostgreSQL?

El Afinamiento o tuning de Bases de Datos PostgreSQL (Performance Tuning de Base de Datos PostgreSQL) es el proceso de cambiar la configuración de la base de datos en un esfuerzo por obtener un mejor rendimiento de ésta. Esto requiere una comprensión profunda de la arquitectura y de cómo funciona el motor de la base de datos, qué hace cada parámetro de configuración y qué valores deben usarse.

Ajustar el rendimiento de PostgreSQL no es similar a ajustar otras bases de datos, como por ejemplo Oracle. Esto se debe a que, con PostgreSQL, puede activar cada esquema para una métrica de rendimiento diferente según el caso de uso, por ejemplo, escrituras o lecturas frecuentes.

Arquitectura PostgreSQL

El servidor PostgreSQL tiene una estructura clásica en los RDBMS, que consiste en una memoria compartida (shared pool), un conjunto de procesos backgrounds y una estructura de directorios de datos que forman la base de datos propiamente tal. A las estructuras de memoria y procesos background se le denomina Instancia PostgreSQL. En esta sección, hablaremos de las componentes principales de la Instancia.

A continuación, se muestra Ilustración 1 Arquitectura PostgreSQL. Inicialmente, el cliente envía una petición al servidor postmaster para abrir un canal de comunicación (sesión). El servidor postmaster que está escuchando por conexiones nuevas, crea un proceso servidor para que atienda al proceso cliente, y estos dos últimos procesos quedan comunicándose en un esquema peer to peer. Luego, el proceso cliente envía alguna petición SQL al su proceso servidor, y el proceso servidor PostgreSQL procesa los datos utilizando bufferes compartidos y procesos background. El archivo físico de datos PostgreSQL se almacena en el directorio de datos. Todo buffer de datos en memoria tiene una imagen en disco. Cuando se consulta un dato, si es que el buffer que contiene ese dato no está memoria se debe cargar desde un bloque en disco a memoria, esta imagen en memoria del bloque o página en disco se denomina buffer.

Tuning de bases de datos PostgreSQL

Ilustración 1 Arquitectura PostgreSQL

Cómo ajustar el rendimiento de PostgreSQL

Hay muchas formas de realizar un Tuning de bases de datos PostgreSQL. Depende principalmente del caso de uso, por lo que es importante saber qué quiere lograr antes de comenzar. Hay varios parámetros de configuración que se pueden usar para realizar ajustes, algunos de los cuales analizaré en esta sección. Por ejemplo, si la base de datos soporta un sistema OLTP orientado a transacciones, como un sistema de ventas – que tiene una configuración recomendada – o por otro lado, si el sistema es un DSS o, incluso, un sistema BATCH, presentan configuraciones diferentes orientadas a servir consultas con alto nivel de I/O. Las estructuras de memoria cambian en estos casos.

Diseño de base de datos

Podría decirse que el diseño de la base de datos es uno de los pasos más importantes para optimizar el rendimiento de cualquier base de datos, no solo de PostgreSQL. Uno observa que en la práctica es una de las actividades que menos se hace, porque en general, los desarrolladores ignoran las claves de la arquitectura de RDBMS y los elementos que influyen en un buen rendimiento de BD. Indexar las columnas FKs, particionar, son acciones elementales que pueden mejorar mucho el rendimiento. Tener índices adecuados depende en gran medida del caso de uso y de las consultas que ejecutará con frecuencia. La idea aquí es filtrar la mayor cantidad de datos posible para que haya menos datos para cargar en memoria. Por lo tanto, debe crear índices en columnas que normalmente se utilizan como filtros (cláusula WHERE ) en las consultas ejecutadas con más frecuencia.

Advertencia: Aunque los índices ayudan a mejorar el rendimiento de las consultas, asegúrese de utilizarlos con precaución. El uso excesivo de índices provocará efectos adversos. Crear y mantener índices es una operación costosa y crear demasiados índices deteriorará el rendimiento general de la base de datos.

Ajuste de hardware

El hardware subyacente definitivamente tiene un papel que desempeñar en la optimización del rendimiento de PostgreSQL. Los desarrolladores deben tener en cuenta la partición, indexación, configuración y capacidad del hardware de los datos al diseñar consultas. Aquí, veremos cuatro componentes de hardware principales y cómo afectan el rendimiento de PostgreSQL.

CPU

La CPU juega un papel importante en el rendimiento de las consultas PostgreSQL. Las operaciones y cálculos complejos, como agregaciones, uniones, hash, agrupaciones, clasificación, etc., requieren tiempo de CPU. Y junto con el tiempo de CPU, la CPU debería ser lo suficientemente poderosa para manejar tales tareas.

Ampliar la capacidad de CPU es una acción que tiene alto costo. Por lo tanto, es necesario realizar un análisis exhaustivo del impacto de la CPU en el rendimiento antes de actualizar la CPU. Al mismo tiempo, se debe pensar lo suficiente en optimizar la consulta para aprovechar al máximo la CPU existente.

Una de las acciones más importantes de un motor de base de datos en consumir un alto nivel de CPU, es la generación del Plan de Ejecución de una consulta. Se deben evaluar los costos de muchos planes de ejecución alternativos, y de debe elegir el “óptimo”, el de menor costo. En la medida que las consultas sean complejas, la cantidad de planes a evaluar será muy grande, y el esfuerzo de cálculo en la evaluación será mayor.

RAM

La RAM o la memoria es crucial para que las bases de datos funcionen correctamente. El buffer pool de la instancia PostgreSQL vive en la RAM. Siempre que enviamos una consulta, los datos primero se guardan en la memoria y luego se aplica cualquier agregación, agrupación, clasificación, etc. Por eso es importante asegurarse de tener suficiente memoria para guardar sus datos.

Con mayor memoria, también verá un mayor caché de disco y operaciones de I/O reducidas en el disco. Esto mejora significativamente el rendimiento de las consultas PostgreSQL, ya que las operaciones de I/O son mucho más caras que las operaciones en la memoria. Nunca está mal tener un poco más de memoria de la absolutamente necesaria.

Por otro lado, si no tenemos suficiente memoria, nuestras consultas podrían cerrarse con una excepción de «memoria insuficiente», u otros procesos en ejecución podrían cerrarse abruptamente para dar cabida a nuestras consultas.

I/O de disco

Un disco duro (ya sea magnético o SSD) es donde residen todos los datos. Entonces, cada vez que se envía una consulta, primero se deben leer los datos del disco y cargarlos en la memoria (shared pool). De manera similar, siempre que haya una operación de escritura, los datos deben escribirse en el disco desde la memoria. Todo esto genera costos de I/O de disco.

Un tiempo de lectura y escritura rápido mejora en gran medida el rendimiento de una consulta PostgreSQL, ya que los datos pueden cargarse rápidamente en la memoria o descargarse rápidamente de la memoria. Si hay operaciones de I/O importantes en la base de datos, otra buena idea es almacenar físicamente cada tablespace en una unidad de disco diferente para que el disco no se sobrecargue con solicitudes de operaciones de I/O.

Red

Es posible que optimizar la red no parezca tan importante al principio. Pero a medida que los datos crecen, se puede ver que la red desempeña un papel importante en el rendimiento de las consultas. Los retrasos en la red son uno de los cuellos de botella de rendimiento más comunes. Es importante contar con tarjetas de red confiables, de alta velocidad y con gran ancho de banda. Además, la conectividad de alta velocidad entre nodos es igualmente crucial. Esto permite que los datos fluyan fácil y rápidamente entre máquinas y no bloqueen consultas. Si tiene una arquitectura de N capas, hay que tratar de minimizar el viaje de datos desde la capa de datos a la capa lógica de negocio, tratando de procesar la máxima información en la base de datos misma, por ejemplo, vía procedimiento o funciones almacenadas.

Optimización del sistema operativo

El sistema operativo desempeña un papel importante en el rendimiento de una base de datos, ya que es la capa que permite la comunicación entre el software de la base de datos y el hardware subyacente. Por ejemplo, si un sistema operativo no puede leer grandes pedazos de archivos de datos del disco a la memoria, el rendimiento general será deficiente.

Cada sistema operativo proporciona muchos parámetros de configuración para ajustar el rendimiento y adaptarlo mejor a nuestro caso de uso. Con una configuración personalizada podemos mejorar significativamente el rendimiento de lectura y escritura de nuestras bases de datos PostgreSQL. Los sistemas operativos también brindan capacidades que el software de bases de datos generalmente no incluye y, sin embargo, dependen de dichas características para su correcto funcionamiento.

Un ejemplo de esto es mantener activa y abierta una conexión TCP entre un servidor de base de datos y un cliente. Normalmente en las bases de datos PostgreSQL  se ven errores como los siguientes:

  • could not receive data from client: Connection reset by peer
  • server closed the connection unexpectedly

Estos errores ocurren cuando se pierde una conexión entre un servidor y un cliente. Puede haber muchas causas para este error, pero la razón más común es que el socket TCP esté cerrado. Siempre que una conexión está inactiva durante un período de tiempo específico, la conexión finaliza automáticamente.

Para evitar esto, el núcleo de cada sistema operativo tiene mecanismos para enviar periódicamente señales de «mantenimiento» al otro sistema para asegurarse de que la conexión esté abierta. Debido a que esta característica la proporciona el kernel del sistema operativo y no la base de datos, PostgreSQL la usa para una conexión confiable entre varios sistemas.

De forma predeterminada, tanto los sistemas Windows como Linux vienen con un tiempo de inactividad configurado de 2 horas. Linux envía una señal de mantenimiento de actividad cada 75 segundos y Windows envía la misma señal cada segundo. Puede ajustar estos parámetros de configuración para que se adapten mejor a sus necesidades.

Ajuste de los parámetros de configuración de la base de datos

PostgreSQL viene con una serie de parámetros de configuración para optimizar su rendimiento.

Parámetros de configuración de conexión

max_connections afecta el comportamiento del servidor PostgreSQL y de las conexiones del cliente. Puede usar esto para configurar la cantidad máxima de conexiones paralelas que un servidor PostgreSQL puede admitir. La fórmula utilizada para calcular esto es:

max_connections = max (4 * number of CPU cores, 100)

Esto garantiza que, en un momento dado, la CPU no se sobrecargue con demasiadas conexiones activas. Pero también debemos asegurarnos de tener suficientes recursos de hardware para admitir esta cantidad de conexiones paralelas.

Parámetros de configuración de la memoria

Los siguientes parámetros de configuración rigen cómo utilizan la memoria del sistema varios procesos y características de la base de datos PostgreSQL. Es importante tener en cuenta que todas las configuraciones relacionadas con la memoria combinadas no deben exceder la cantidad máxima de memoria disponible.

Shared_buffers (buffer pool) determina la cantidad de memoria que PostgreSQL puede utilizar para los buffers de memoria compartida. Es una buena regla general no asignar más del 25% de la memoria disponible para esto.

temp_buffers determina la cantidad de memoria utilizada para los buffers temporales para cada sesión de base de datos. Debido a que esto es local para cada sesión, se debe multiplicar por el número de sesiones activas para obtener la cantidad máxima que puede alcanzar.

wal_buffers es la cantidad de memoria de búferes compartidos que se utilizará para almacenar en el búfer los datos WAL antes de que puedan escribirse en el disco. De forma predeterminada, el valor se establece en -1, lo que equivale aproximadamente al 3 % del tamaño de los búferes compartidos (shared buffers). No puede ser inferior a 64 KB ni superior al tamaño de un segmento WAL, que suele ser de 16 MB.

work_mem es la cantidad máxima de memoria que una consulta puede usar para su operación, por ejemplo, como ordenaciones, tablas hash, etc. Se debe tener en cuenta que este límite es por consulta y no para toda la base de datos. De forma predeterminada, el límite está establecido en 4 MB, que se puede cambiar para adaptarse mejor a sus casos de uso.

Maintenance_work_mem es la cantidad de memoria asignada para realizar actividades de mantenimiento en la base de datos, como crear índices, alterar tablas, aspirar, cargar datos, etc. Generalmente, cuando se realizan estas operaciones, hay un aumento en las operaciones de I/O del disco, ya que los cambios deben escribirse en el disco. La forma óptima de hacerlo sería realizar tantas operaciones como sea posible en la memoria y escribir la salida final en el disco, reduciendo así las costosas operaciones de I/O  del disco. Por lo que tener al menos 1 GB de memoria para trabajos de mantenimiento es un buen punto de partida.

Parámetros de configuración del registro WAL

El registro Write Ahead Log  (WAL)  es una bitácora que registra en una forma secuencial todos los cambios que se han realizado en la Base de Datos. Este registro WAL garantiza que todos los cambios en los datos se registren en los archivos de bitácora antes de que dichos cambios se materialicen en los archivos de datos propiamente tal, de modo que, en caso de fallas, el registro pueda reproducir la historia más reciente de cambios (desde el último checkpoint) hasta recuperar los cambios en los bloques de datos. Los siguientes son algunos de los parámetros de configuración relacionados con la bitácora WAL que pueden generar mejoras de rendimiento para una base de datos PostgreSQL.

fsync se asegura de que todas las actualizaciones de los datos se escriban primero en el disco. Esta es una medida para recuperar datos después de una falla de software o hardware. Como puede imaginar, estas operaciones de escritura en disco son costosas y podrían afectar negativamente al rendimiento. Pero esto también garantiza que se mantenga la integridad de los datos, una compensación que depende del caso de uso.

commit_delay establece la cantidad de tiempo que debe esperar un vaciado de WAL residente en memoria, antes de vaciar el registro en el disco. De esta manera, se puede descargar más de una transacción al disco a la vez, mejorando el rendimiento general. Pero asegúrese de que no sea demasiado largo, o de lo contrario se podría perder una cantidad significativa de transacciones en caso de falla.

checkpoint_timeout indica la cantidad máxima de tiempo entre dos checkpoints en la bitácora WAL. El rango es de 30 segundos a 1 día y el valor predeterminado es 5 minutos. Se debe señalar aquí que si este valor es significativamente grande, el tiempo necesario para la recuperación de datos después de una falla también será mayor (RTO).

checkpoint_completion_target indica cómo se deben completar las escrituras del CHECKPOINT dentro del intervalo checkout_timeout. El valor predeterminado es 0,9, lo que significa que las escrituras en el disco se distribuirán el 90% del tiempo entre dos puntos de control. De esta manera, las operaciones de I/O no sobrecargan la CPU ni causarán problemas. Hay una distribución uniforme de las operaciones de escritura, como se esperaba. Además, de esta manera, también hay suficiente tiempo para overhead. Sin embargo, no se recomienda cambiar este valor.

checkpoint_segments es el número máximo de segmentos que puede haber entre checkpoints. De forma predeterminada, habrá tres segmentos y cada segmento tendrá 16 MB. Aumentar el número de segmentos también aumentará el tiempo necesario para la recuperación de datos después de un fallo.

checkpoint_segments está obsoleto para la versión 9.5 y superiores, ya que ha sido reemplazado por min_wal_size y max_wal_size . Si previamente ajustó checkpoint_segments, la siguiente fórmula le dará una configuración aproximadamente equivalente:
max_wal_size = (3 * checkpoint_segments) * 16MB

Tenga en cuenta que la configuración predeterminada para max_wal_size es mucho mayor que la que solían ser los checkpoint_segments predeterminados, por lo que es posible que ya no sea necesario ajustarla.

Consultar parámetros de configuración de costos

El planificador de consultas utiliza una variedad de parámetros y señales de configuración para calcular el costo de cada consulta. Algunos de estos parámetros se enumeran a continuación y pueden mejorar potencialmente el rendimiento de una consulta PostgreSQL.

random_page_cost establece el costo para el planificador por recuperar una página de disco de forma no secuencial. El valor predeterminado es 4. También puede configurar esto en el nivel del espacio de tabla. Reducir el valor a menos de 4 hará que el planificador prefiera los escaneos de índice. Aumentarlo le indicará al planificador que los escaneos de índice son más caros.

Effective_cache_size es una estimación del tamaño efectivo de la caché de disco disponible para cada consulta. Este costo se suma al gasto de utilizar un escaneo índice o un escaneo secuencial. El valor predeterminado aquí es 4 GB, que puedes modificar.

Inicio sesión

PostgreSQL también ofrece algunos parámetros de configuración para el registro , que pueden ayudar a mejorar el mantenimiento de una base de datos PostgreSQL.

logging_collector le permite capturar todos los mensajes de registro enviados al registrador de errores estándar y luego los redirige a un archivo de registro . De esta manera, podemos estar seguros de que se capturan todos los mensajes de registro, incluso aquellos que no aparecen en el syslog .

log_statement controla qué tipos de consultas se registran en los archivos de registro. Las opciones aquí incluyen none, ddl, mod y all. Las DDL son consultas que se utilizan para crear, modificar o eliminar tablas. Las consultas MOD se utilizan para insertar, actualizar, eliminar, truncar y otras operaciones similares en una tabla.

log_min_error_statement establece el nivel de registro mínimo en el que las consultas SQL que generan dichos errores se registran en el registro del sistema. Los valores incluyen DEBUG1, DEBUG2, INFO, AVISO, ADVERTENCIA, ERROR, FATAL, etc.

log_line_prefix es una cadena de estilo printf que puede anteponer al inicio de cada línea de registro. El carácter % comienza la secuencia de escape. Luego se reemplaza con información de estado según la opción proporcionada. Hay opciones para rellenar el prefijo del registro hacia la derecha o hacia la izquierda.

log_lock_waits controla si se generará un mensaje de registro después de que transcurra el período deadlock_timeout. Esto da una indicación clara de si las esperas de bloqueo son la razón del bajo rendimiento. De forma predeterminada, esta configuración está desactivada y requiere que se active el permiso de superusuario.

log_checkpoints registra los puntos de control y los puntos de reinicio en el registro del servidor. Además de esto, la cantidad de búferes escritos y el tiempo necesario para escribir estos búferes también se incluyen en el mensaje de registro, lo que permite una mejor comprensión y depuración.

Vacuum

En PostgreSQL, cuando se actualiza o elimina una fila o tupla, el registro en realidad no se elimina ni se modifica físicamente. Esto deja registros obsoletos en el disco, lo que consume espacio en el disco y también afecta negativamente el rendimiento de las consultas. Para solucionar este problema, PostgreSQL proporciona una función interesante llamada Vacuum que permite borrar fácilmente dichos registros del disco y recuperar espacio, mejorando también el rendimiento de las consultas.

El comando Vacuum viene con muchas opciones. Por ejemplo, puede utilizar el comando VACUUM ANALYZE para eliminar físicamente primero los registros obsoletos; luego, ejecute automáticamente la operación ANALYSE para actualizar las estadísticas de una tabla para que el optimizador de consultas planifique mejores consultas futuras en esa tabla.

O puede utilizar el comando VACUUM FULL para hacer más con el espacio liberado. El comando Vacuum en sí eliminará primero los registros de la tabla y mantendrá el espacio libre en disco recién adquirido con la tabla para uso futuro, para cuando la tabla crezca. Esto no liberará espacio en disco para el sistema operativo. Pero usar la opción COMPLETA con el comando en realidad reescribirá la tabla completa en un nuevo archivo de disco; cualquier espacio en disco que se libere se devolverá al sistema operativo para que lo utilicen otros procesos. Debido a esto, VACUUM FULL no se puede utilizar en paralelo con ninguna otra operación de lectura o escritura en la mesa. Sólo el comando VACUUM se puede ejecutar en paralelo.

Dada la importancia del proceso de vacío, PostgreSQL viene con una versión automatizada de este llamado autovacuum. El proceso de autovacuum comprende varios módulos que funcionan en conjunto para ejecutar automáticamente el comando Vacuum a intervalos regulares para garantizar que todos los registros obsoletos se eliminen de las tablas para que sus consultas funcionen mejor.

Al igual que con cualquier otro componente de PostgreSQL, puede configurar el proceso de autovacuum para adaptarlo a sus necesidades comerciales. De esta manera, puede programarlo en momentos en que hay menos operaciones ejecutándose en las tablas para asegurarse de que incluso la ejecución paralela no tenga impacto en las tablas.

Los administradores de bases de datos pueden ejecutar el comando Vacuum con cualquiera de sus opciones en cualquier momento, de forma ad hoc y en tablas particulares, sino en toda la base de datos.

Ajuste del rendimiento de consultas

Es importante comprender cómo PostgreSQL ejecuta nuestra consulta sobre los datos para que pueda ajustar la consulta o la propia base de datos para que funcione mejor. Hay algunos comandos que le ayudan a optimizar automáticamente el rendimiento de las consultas.

ANALYZE

Analyze es un comando que puede ejecutar en sus bases de datos y tablas para medir algunas estadísticas sobre las tablas. Estas estadísticas calculadas luego se almacenan en una tabla mantenida por PostgreSQL, que luego será utilizada por el planificador de consultas para planificar mejor la ejecución de las consultas. Cuando envía una consulta, primero se transforma en PostgreSQL. Luego pasa al optimizador, que elabora un plan para la ejecución de la consulta.

El optimizador utiliza las estadísticas de una tabla para formar el plan de ejecución. Pero con el tiempo, las estadísticas se vuelven obsoletas y poco representativas y es posible que el plan de ejecución no sea preciso o no funcione correctamente. Por lo tanto, se debe asegurar de que las estadísticas estén siempre actualizadas. Aquí es donde entra en juego el comando de ANALYZE. Cuando se ejecuta, el comando vuelve a calcular las estadísticas de la tabla dada y las actualiza en la base de datos. Esto luego se utilizará para generar los planes de ejecución.

EXPLAIN

Después del comando ANALYZE, EXPLAIN es el siguiente paso lógico para ajustar el rendimiento de las consultas PostgreSQL. Esto genera el plan DE EJECUCIÓN que forma la base de datos después de usar las estadísticas calculadas por el comando de análisis. Esto debería darnos una idea clara de cómo se realizará la consulta, si utilizará un escaneo de índice o un escaneo de tabla, etc. En base a esto, podemos modificar la consulta para un mejor rendimiento o actualizar las estadísticas. ejecutando analizar nuevamente.

Rendimiento de indexación

La indexación lo es todo cuando se trata del rendimiento de las consultas. Podemos ver una inmensa diferencia en el rendimiento de las consultas con y sin índices. Pero este no es siempre el caso. Debe comprender cómo la indexación puede afectar el rendimiento de las consultas en función de una serie de factores, como el tamaño de la tabla, cómo accederá a los datos de una tabla, cuál es el algoritmo de indexación, etc.

Esto requiere una comprensión profunda de todos los casos de uso en una tabla. Además, debe tener en cuenta que cada vez que se actualizan los datos en una tabla indexada, los índices también deben actualizarse, lo que agrega una sobrecarga.

Herramientas de ajuste de rendimiento de PostgreSQL

La optimización del rendimiento de PostgreSQL, o Tuning de bases de datos PostgreSQL, depende de varios factores que debe vigilar constantemente. Para ello, necesitará una herramienta de seguimiento adecuada que le permita identificar fácilmente los cuellos de botella y decidir las acciones adecuadas. Esta solución le ayudará a responder preguntas tales como

  • ¿Necesito agregar más recursos en mi servidor físico?
  • ¿Tengo algunas consultas de ejecución lenta que están afectando el rendimiento de PostgreSQL?
  • ¿Necesito más índices para tener una respuesta más rápida a una consulta realizada con frecuencia?
  • ¿Necesito cambiar mi configuración de PostgreSQL para limitar la cantidad máxima de conexiones?

Existe una variedad de herramientas que pueden conectarse a una base de datos PostgreSQL y recopilar métricas útiles para solucionar problemas. Cada herramienta tiene sus propias áreas de enfoque. La mayoría puede acceder no sólo a la base de datos PostgreSQL, sino también al sistema operativo. Esto ayuda a recopilar métricas que se pueden analizar juntas y extraer inferencias sobre cómo los recursos del sistema afectan o se ven afectados por el rendimiento de las consultas.

La mayoría de las soluciones de monitoreo de PostgreSQL ofrecen versiones gratuitas o de prueba que puede configurar fácilmente para ver qué ofrecen y cómo pueden ayudarlo a monitorear y optimizar el rendimiento de la base de datos . Y añaden poca sobrecarga al funcionamiento normal de una base de datos PostgreSQL.

Si está buscando una solución de este tipo, consulte esta comparación de las mejores herramientas de monitoreo de PostgreSQL disponibles en este momento.

Monitorear PostgreSQL con Zabbix

Zabbix es una solución de monitoreo de pila completa para monitoreo y registro de PostgreSQL . Facilita comenzar a monitorear las métricas de PostgreSQL sin muchos problemas: solo necesita instalar un agente liviano en la máquina y todo debería estar listo. Obtiene acceso instantáneo a paneles de monitoreo, alertas y reglas de detección de anomalías listos para usar que luego puede personalizar fácilmente para satisfacer sus necesidades comerciales.

Además de monitorear el propio PostgreSQL, Zabbix también puede monitorear cualquier aplicación y contenedor que se conecte a PostgreSQL. Junto con la capacidad de capturar automáticamente registros de PostgreSQL, la herramienta hace que sea mucho más fácil detectar problemas con su base de datos y todo el entorno. 

Zabbix es capaz de monitorear bases de datos PostgreSQL sin importar dónde estén alojadas, en bare metal o en la nube con cualquier proveedor de infraestructura en la nube. 

Tuning de bases de datos PostgreSQL


Lea lo último de nuestro blog: «La familia de productos de bases de datos Oracle».

Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *