BB BitBunker HQ

Monitoring en Acción

Observabilidad de PostgreSQL con Prometheus + Grafana. Aquí contamos la historia de la última prueba relevante (baseline → carga → resultados), y al final listamos todos los casos anteriores.

1. Situación inicial

Entorno estable y de baja actividad para establecer un baseline: conexiones mínimas a la base y a la instancia, TPS plano, ausencia de deadlocks. Esto nos da un punto de comparación para los cambios.

KPIs iniciales: conexiones, TPS, cache hit
Baseline: métricas planas y cache hit > 99%.
Ver más gráficos de la etapa inicial
Actividad de filas (read/change)
Flujo constante de filas leídas (Returned) en reposo, sin operaciones de inserción, actualización o borrado. Confirmamos solo lectura durante la línea base.
Conexiones por estado
Durante la línea base no se registraron conexiones activas ni en espera. La base permaneció en reposo antes de iniciar las pruebas.

2. Pruebas de carga

Ejecutamos pgbench y consultas BI intensivas para simular concurrencia real. Observamos comportamiento bajo presión: latencias, locks, variaciones de TPS y cache hit.

TPS durante las pruebas
Durante la prueba de carga simultánea, el servidor PostgreSQL alcanzó 49 conexiones activas y 2 transacciones abiertas de forma concurrente. El pico de rendimiento fue de 1.15K transacciones por segundo (TPS), con alto volumen de filas leídas, insertadas y actualizadas en tiempo real. Este panel muestra el impacto global de la carga en conexiones, consultas y movimiento de datos.
Ver más gráficos de la prueba
Locks y deadlocks
Locks por modo controlados y 0 deadlocks durante la ejecución: la concurrencia no generó bloqueos críticos.
CPU y RAM durante la prueba
CPU hasta ~0,75% y RAM ~9,15%: aumento controlado sin llegar a saturar la infraestructura.

3. Resultados y balance

Tras dos pruebas de carga independientes, el sistema demostró su capacidad para absorber picos de concurrencia y actividad sin degradación sostenida.

El gráfico muestra cómo, al finalizar cada ciclo de carga, las métricas clave —conexiones, TPS, actividad de filas, locks y deadlocks— retornan rápidamente a valores normales.

Este comportamiento confirma un baseline estable post-prueba, validando tanto la configuración de PostgreSQL como la capacidad del entorno para manejar cargas intermitentes sin impacto residual.


La ejecución de las pruebas de carga permitió validar el comportamiento del servidor PostgreSQL bajo un escenario de concurrencia moderada y consultas de alta frecuencia.

Estabilidad del sistema:

No se detectaron errores críticos ni caídas durante las pruebas. Todos los procesos se ejecutaron y finalizaron de forma ordenada, sin comprometer la disponibilidad.

Concurrencia gestionada:

PostgreSQL manejó correctamente las 49 conexiones activas simultáneas y las operaciones concurrentes, manteniendo la latencia baja.

Rendimiento:

Pico de 1.15K TPS, con flujo constante de inserciones, actualizaciones y lecturas sobre grandes volúmenes de filas.

Integridad y ausencia de bloqueos graves:

Locks dentro de valores esperados, sin deadlocks.

Recursos del sistema:

CPU y memoria con incremento controlado, confirmando margen para cargas más exigentes.

Conclusión:

El entorno absorbió picos de actividad sin degradar el servicio: configuración apta para escenarios reales y espacio para escalar en próximos ensayos.

Dashboard tras pruebas de carga
Visión global tras las pruebas: recuperación estable y sin impacto residual.