Herramientas de IO y Memoria

iostat, vmstat, pidstat en hosts PostgreSQL 18.4 en Linux - vincula métricas del host a PIDs de postgres durante incidentes de IO y memoria.

Receta

# Instantánea de IO (paquete sysstat)
iostat -xz 1 5
 
# Vista de memoria y planificador de CPU
vmstat 1 5
 
# RSS por proceso para PIDs de postgres
pidstat -r -p $(pgrep -d, -f 'postgres:') 1 5

SELECT pid, wait_event_type, wait_event, state, left(query, 60)
FROM pg_stat_activity
WHERE backend_type = 'client backend' AND state = 'active';

Cuándo recurrir a esto:

• latencia p95 alta pero el porcentaje de CPU parece inactivo (espera de IO)
• Actividad OOM o de swap durante consultas grandes de ordenación/hash aggregate
• Autovacuum o punto de control sospechosos de saturar el disco

Ejemplo de Trabajo

Síntoma: Tiempos de espera de API; CPU de Postgres 30% pero latencia alta.

iostat -xz 1 3

Device  r/s   w/s  rkB/s  wkB/s  %util
nvme0n1 4500  800  72000  12000  98.5

SELECT queryid, calls, mean_exec_time, shared_blks_read, temp_blks_written
FROM pg_stat_statements
ORDER BY shared_blks_read DESC NULLS LAST LIMIT 5;

pidstat -u -p $(pgrep -n -f 'postgres:') 1 3

Interpretación:

• %util cerca del 100% → disco saturado
• Consulta principal con alto shared_blks_read → escaneo secuencial o caché fría
• PID específico con alta CPU en pidstat → correlacionar con pg_stat_activity.pid

Análisis Profundo

Columnas de iostat

Columnas de vmstat

pidstat en Postgres

# RSS de todos los backends de postgres cada segundo
pidstat -r -C postgres 1 5
 
# Un solo backend de pg_stat_activity
pidstat -r -p 284719 1 10

SELECT pid, query, work_mem_needed FROM (
  SELECT pid, left(query,40) AS query
  FROM pg_stat_activity WHERE state = 'active'
) q;

• Las operaciones de ordenación/hash muestran un aumento de RSS en un PID antes de desbordarse al disco (temp_blks_written)

Punto de Control vs IO de Consulta

SELECT checkpoints_timed, checkpoints_req, checkpoint_write_time, buffers_checkpoint
FROM pg_stat_bgwriter;

• Pico de punto de control: tasa de escritura alta, menos filas de consulta activas en pg_stat_activity
• Tormenta de consultas: muchos backends activos con eventos de espera DataFileRead

Trampas

• Culpar a Postgres sin iostat - El estrangulamiento de EBS/NFS parece consultas lentas. Solución: mide %util primero.
• Muestra única de vmstat - pico engañoso. Solución: intervalo de 1 segundo, 5+ muestras.
• pidstat en PID incorrecto - postmaster vs backend. Solución: usa el PID de pg_stat_activity.
• Ignorar el recuento de conexiones - 200 ordenaciones x work_mem agotan la RAM. Solución: agrupa conexiones, reduce el rol de work_mem por consulta.
• Ajustar shared_buffers durante tormenta de swap - no soluciona el swap. Solución: reduce los consumidores de memoria, añade RAM, corrige consultas.

Alternativas

Preguntas Frecuentes

Relacionado

• Conceptos básicos de la CLI de Linux para DBAs - salud del disco y del servicio
• Mejores prácticas de CLI - política de scripting
• Ajuste de Work Mem y Sort Hash - GUCs de memoria
• Escaneo Secuencial vs Escaneo de Índice - amplificación de lectura
• Habilidad de Triaje de Incidentes - rama de IO

Versiones de Stack: Esta página fue escrita para PostgreSQL 18.4 en Linux con sysstat 12+ (iostat, pidstat, vmstat).