Conceptos básicos de la CLI de Linux para administradores de bases de datos

Q: ¿Instalar herramientas adicionales en el host de la base de datos de producción?

Prefiere un bastion con sysstat (iostat), htop. Imagen mínima de producción: usa vmstat, ps, df siempre presentes.

Q: ¿kubectl exec vs SSH?

Kubernetes: kubectl exec -it pod -- bash luego los mismos comandos. Ruta PGDATA desde el entorno o psql -c 'SHOW data_directory;'.

10 ejemplos de señales de disco y memoria durante tormentas de consultas en hosts Linux con PostgreSQL 18.4: triaje con bash antes de cambiar GUCs o realizar failover.

Prerrequisitos

Conéctate por SSH a un bastion o usa kubectl exec en un pod de base de datos (rol de solo lectura para juniors).
Conoce la ruta de PGDATA: /var/lib/postgresql/18/main o el montaje específico del proveedor.
psql en la variable de entorno PATH con credenciales de producción de solo lectura.

export PGDATA=/var/lib/postgresql/18/main
export DATABASE_URL="postgresql://readonly@localhost:5432/myapp"

Ejemplos básicos

1. Espacio en disco en PGDATA

df -h "$PGDATA"
df -i "$PGDATA"   # el agotamiento de inodos parece disco lleno
du -sh "$PGDATA/pg_wal" "$PGDATA/log" 2>/dev/null || true

El crecimiento de WAL sin éxito de archivo llena el disco antes que los archivos de datos
Disco al 100% → Postgres puede dejar de aceptar escrituras con PANIC o FATAL

2. Señales de presión de memoria

free -h
vmstat 1 5
dmesg -T | tail -30 | grep -i -E 'oom|kill|postgres'

SELECT name, setting, unit FROM pg_settings
WHERE name IN ('shared_buffers','work_mem','maintenance_work_mem','effective_cache_size');

El OOM killer apunta a un trabajador postgres con RSS alto durante tormentas de ordenación/hash
work_mem multiplicado por las ordenaciones concurrentes puede exceder la RAM sin límites de pool de conexiones

3. Quién está ejecutando qué

SELECT pid, usename, application_name, client_addr, state, wait_event_type, wait_event,
       now() - query_start AS duration, left(query, 100) AS query
FROM pg_stat_activity
WHERE datname = current_database() AND pid <> pg_backend_pid()
ORDER BY duration DESC NULLS LAST
LIMIT 20;

wait_event_type = IO durante una tormenta de checkpoint o escaneo secuencial
idle in transaction retiene bloqueos y hincha el vacuum

4. Conteo rápido de esperas de bloqueo

SELECT count(*) FILTER (WHERE NOT granted) AS waiting,
       count(*) FILTER (WHERE granted) AS granted
FROM pg_locks;

# One-liner desde la shell vía psql
psql "$DATABASE_URL" -t -c "SELECT count(*) FROM pg_locks WHERE NOT granted;"

5. Salud del servicio Postgres (systemd)

sudo systemctl status postgresql@18-main
sudo journalctl -u postgresql@18-main -p err --since "30 min ago" --no-pager

El bucle de reinicio a menudo se correlaciona con OOM o configuración corrupta después de una edición
El journal muestra FATAL: could not write lock file en disco lleno

6. Encontrar procesos de Postgres

ps aux | grep '[p]ostgres'
pgrep -a postgres

# Trabajadores de postgres con mayor RSS
ps -eo pid,rss,cmd --sort=-rss | grep postgres | head -10

Muchas líneas de postgres: worker son normales; un trabajador con RSS gigante puede ser un nodo de ordenación/hash

7. Conexiones de red al puerto 5432

ss -tnp | grep ':5432'
ss -s   # resumen: established, timewait

Tormenta de conexiones desde la aplicación sin pooler muestra miles de ESTAB
Comparar con max_connections en SQL

Ejemplos intermedios

8. Script de paquete de incidentes

#!/usr/bin/env bash
set -euo pipefail
OUT="incident-$(date +%Y%m%d-%H%M%S)"
mkdir -p "$OUT"
df -h > "$OUT/df.txt"
free -h > "$OUT/free.txt"
vmstat 1 5 > "$OUT/vmstat.txt"
psql "$DATABASE_URL" -v ON_ERROR_STOP=1 -c "SELECT version();" > "$OUT/version.txt"
psql "$DATABASE_URL" -c "SELECT * FROM pg_stat_activity;" > "$OUT/activity.csv" --csv
psql "$DATABASE_URL" -c "SELECT * FROM pg_locks WHERE NOT granted;" > "$OUT/locks.csv" --csv
tar czf "$OUT.tgz" "$OUT"
echo "bundle: $OUT.tgz"

Adjuntar el paquete al ticket de incidente dentro de los primeros 15 minutos
El escriba ejecuta el script; el comandante del incidente interpreta

9. Correlacionar IO del host con tormenta de consultas

iostat -xz 1 5

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

%util creciente en el volumen de datos más escaneos secuenciales en las declaraciones principales → problema de índice o caché
Ver Herramientas de IO y Memoria

10. Parada segura de Postgres vs Kill

# Graceful (systemd)
sudo systemctl stop postgresql@18-main
 
# Emergencia solo después de que la parada falló
sudo kill -TERM "$(head -1 "$PGDATA/postmaster.pid")"
sleep 10
# kill -9 último recurso - riesgo de checkpoint incompleto

SIGKILL en el postmaster arriesga la recuperación en el próximo inicio; documentar en el post-mortem

Preguntas frecuentes

¿Instalar herramientas adicionales en el host de la base de datos de producción?

Prefiere un bastion con sysstat (iostat), htop. Imagen mínima de producción: usa vmstat, ps, df siempre presentes.

¿kubectl exec vs SSH?

Kubernetes: kubectl exec -it pod -- bash luego los mismos comandos. Ruta PGDATA desde el entorno o psql -c 'SHOW data_directory;'.

¿Cuándo escalar a failover?

Hardware muerto, PANIC de corrupción, o disco irrecuperable - no para cada tormenta de bloqueos. Ver Habilidad de Triaje de Incidentes.

Relacionados

Herramientas de IO y Memoria - iostat, vmstat, pidstat
Mejores prácticas de CLI - Resumen de 25 elementos
Habilidad de Triaje de Incidentes - árbol de decisiones
Disco lleno en PGDATA - runbook de WAL
Triaje de tormentas de bloqueo - consultas bloqueantes

Versiones de pila: Esta página fue escrita para PostgreSQL 18.4 en Linux (systemd, diseños Debian/RHEL).

Prerrequisitos

Conéctate por SSH a un bastion o usa kubectl exec en un pod de base de datos (rol de solo lectura para juniors).
Conoce la ruta de PGDATA: /var/lib/postgresql/18/main o el montaje específico del proveedor.
psql en la variable de entorno PATH con credenciales de producción de solo lectura.

export PGDATA=/var/lib/postgresql/18/main
export DATABASE_URL="postgresql://readonly@localhost:5432/myapp"

Ejemplos básicos

1. Espacio en disco en PGDATA

df -h "$PGDATA"
df -i "$PGDATA"   # el agotamiento de inodos parece disco lleno
du -sh "$PGDATA/pg_wal" "$PGDATA/log" 2>/dev/null || true

El crecimiento de WAL sin éxito de archivo llena el disco antes que los archivos de datos
Disco al 100% → Postgres puede dejar de aceptar escrituras con PANIC o FATAL

2. Señales de presión de memoria

free -h
vmstat 1 5
dmesg -T | tail -30 | grep -i -E 'oom|kill|postgres'

SELECT name, setting, unit FROM pg_settings
WHERE name IN ('shared_buffers','work_mem','maintenance_work_mem','effective_cache_size');

El OOM killer apunta a un trabajador postgres con RSS alto durante tormentas de ordenación/hash
work_mem multiplicado por las ordenaciones concurrentes puede exceder la RAM sin límites de pool de conexiones

3. Quién está ejecutando qué

SELECT pid, usename, application_name, client_addr, state, wait_event_type, wait_event,
       now() - query_start AS duration, left(query, 100) AS query
FROM pg_stat_activity
WHERE datname = current_database() AND pid <> pg_backend_pid()
ORDER BY duration DESC NULLS LAST
LIMIT 20;

wait_event_type = IO durante una tormenta de checkpoint o escaneo secuencial
idle in transaction retiene bloqueos y hincha el vacuum

4. Conteo rápido de esperas de bloqueo

SELECT count(*) FILTER (WHERE NOT granted) AS waiting,
       count(*) FILTER (WHERE granted) AS granted
FROM pg_locks;

# One-liner desde la shell vía psql
psql "$DATABASE_URL" -t -c "SELECT count(*) FROM pg_locks WHERE NOT granted;"

5. Salud del servicio Postgres (systemd)

sudo systemctl status postgresql@18-main
sudo journalctl -u postgresql@18-main -p err --since "30 min ago" --no-pager

El bucle de reinicio a menudo se correlaciona con OOM o configuración corrupta después de una edición
El journal muestra FATAL: could not write lock file en disco lleno

6. Encontrar procesos de Postgres

ps aux | grep '[p]ostgres'
pgrep -a postgres

# Trabajadores de postgres con mayor RSS
ps -eo pid,rss,cmd --sort=-rss | grep postgres | head -10

Muchas líneas de postgres: worker son normales; un trabajador con RSS gigante puede ser un nodo de ordenación/hash

7. Conexiones de red al puerto 5432

ss -tnp | grep ':5432'
ss -s   # resumen: established, timewait

Tormenta de conexiones desde la aplicación sin pooler muestra miles de ESTAB
Comparar con max_connections en SQL

Ejemplos intermedios

8. Script de paquete de incidentes

#!/usr/bin/env bash
set -euo pipefail
OUT="incident-$(date +%Y%m%d-%H%M%S)"
mkdir -p "$OUT"
df -h > "$OUT/df.txt"
free -h > "$OUT/free.txt"
vmstat 1 5 > "$OUT/vmstat.txt"
psql "$DATABASE_URL" -v ON_ERROR_STOP=1 -c "SELECT version();" > "$OUT/version.txt"
psql "$DATABASE_URL" -c "SELECT * FROM pg_stat_activity;" > "$OUT/activity.csv" --csv
psql "$DATABASE_URL" -c "SELECT * FROM pg_locks WHERE NOT granted;" > "$OUT/locks.csv" --csv
tar czf "$OUT.tgz" "$OUT"
echo "bundle: $OUT.tgz"

Adjuntar el paquete al ticket de incidente dentro de los primeros 15 minutos
El escriba ejecuta el script; el comandante del incidente interpreta

9. Correlacionar IO del host con tormenta de consultas

iostat -xz 1 5

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

%util creciente en el volumen de datos más escaneos secuenciales en las declaraciones principales → problema de índice o caché
Ver Herramientas de IO y Memoria

10. Parada segura de Postgres vs Kill

# Graceful (systemd)
sudo systemctl stop postgresql@18-main
 
# Emergencia solo después de que la parada falló
sudo kill -TERM "$(head -1 "$PGDATA/postmaster.pid")"
sleep 10
# kill -9 último recurso - riesgo de checkpoint incompleto

SIGKILL en el postmaster arriesga la recuperación en el próximo inicio; documentar en el post-mortem

Preguntas frecuentes

¿Instalar herramientas adicionales en el host de la base de datos de producción?

Prefiere un bastion con sysstat (iostat), htop. Imagen mínima de producción: usa vmstat, ps, df siempre presentes.

¿kubectl exec vs SSH?

Kubernetes: kubectl exec -it pod -- bash luego los mismos comandos. Ruta PGDATA desde el entorno o psql -c 'SHOW data_directory;'.

¿Cuándo escalar a failover?

Hardware muerto, PANIC de corrupción, o disco irrecuperable - no para cada tormenta de bloqueos. Ver Habilidad de Triaje de Incidentes.

Relacionados

Herramientas de IO y Memoria - iostat, vmstat, pidstat
Mejores prácticas de CLI - Resumen de 25 elementos
Habilidad de Triaje de Incidentes - árbol de decisiones
Disco lleno en PGDATA - runbook de WAL
Triaje de tormentas de bloqueo - consultas bloqueantes

Versiones de pila: Esta página fue escrita para PostgreSQL 18.4 en Linux (systemd, diseños Debian/RHEL).

Conceptos básicos de la CLI de Linux para administradores de bases de datos

Buscar en la documentación

Conceptos básicos de la CLI de Linux para administradores de bases de datos