El monitoreo permite detectar cuellos de botella en el sistema físico (CPU, memoria, disco, red).
Una base de datos optimizada a nivel lógico puede seguir rindiendo mal si el servidor está saturado.
🔸 1. CPU
La CPU se usa para procesar consultas, ordenar datos, aplicar filtros, etc.
El síntoma típico de CPU saturada es un aumento de los tiempos de respuesta, especialmente en consultas complejas o con muchas agregaciones.
📘 Herramientas comunes:
Linux: top, htop, vmstat
Windows: Monitor de rendimiento (Performance Monitor)
SGBD: pg_stat_activity (PostgreSQL), SHOW PROCESSLIST (MySQL)
✅ Buenas prácticas:
Revisar consultas costosas (EXPLAIN ANALYZE).
Evitar funciones o transformaciones innecesarias en las consultas.
Ajustar paralelismo (max_parallel_workers_per_gather en PostgreSQL, MAXDOP en SQL Server).
🔸 2. Memoria (RAM)
La memoria es clave para el caché y el procesamiento interno del SGBD.
Si es insuficiente, el motor recurre al disco, lo que degrada notablemente el rendimiento.
📘 Indicadores:
Uso de swap → señal de falta de memoria.
Alta actividad de disco por lectura de páginas → buffers pequeños.
✅ Buenas prácticas:
Aumentar shared_buffers o innodb_buffer_pool_size.
Asignar suficiente work_mem para operaciones grandes.
Evitar ejecutar demasiadas consultas simultáneamente.
🔸 3. Disco (I/O)
El almacenamiento es el factor más lento en todo el sistema.
Las operaciones de escritura y lectura intensivas pueden ser un cuello de botella.
📘 Herramientas de monitoreo:
Linux: iostat, iotop
Windows: Resource Monitor
PostgreSQL: vistas pg_stat_io, pg_stat_bgwriter
✅ Buenas prácticas:
Usar discos SSD o NVMe para reducir latencia.
Separar los archivos de datos, logs y backups en discos distintos.
Mantener índices actualizados (REINDEX, ANALYZE).
🔸 4. Entrada/Salida de Red
En sistemas distribuidos o aplicaciones web, la latencia de red puede impactar el tiempo total de las consultas.
✅ Recomendaciones:
Minimizar el tráfico entre aplicación y base (consultas eficientes).
Usar connection pooling (p. ej. PgBouncer o HikariCP).
