La CLI de Linux
Un servidor PostgreSQL no se ejecuta de forma aislada, se ejecuta como un proceso en un host Linux que tiene sus propios límites de disco, memoria y red, por lo que leer la línea de comandos es en realidad leer una segunda capa debajo de la propia base de datos.
Esta página construye el modelo mental para esa lectura: las tres capas que una sesión de triaje correlaciona, la doctrina que evita que un operador cambie cosas a ciegas y dónde termina la evidencia de la CLI y comienza una decisión a nivel de base de datos.
Resumen
- La CLI de Linux proporciona al operador una segunda vista independiente de un clúster de Postgres, la vista del sistema operativo, que debe correlacionarse con la vista propia de la base de datos, no sustituirla.
- Por Qué Importa: Los síntomas que parecen específicos de la base de datos, como una tormenta de consultas, a menudo son en realidad un agotamiento a nivel de host de disco, memoria o descriptores de archivos que se disfrazan de Postgres.
- Conceptos Clave: correlación de tres capas, doctrina de triaje, paquete de incidentes, parada segura frente a matar, eventos de espera.
- Cuándo Usar: Utiliza este modelo en el momento en que un sistema se sienta lento o no responda y aún no sepas si la causa reside en el SO, el proceso de Postgres o la carga de trabajo en sí.
- Limitaciones / Compensaciones: La evidencia de la CLI te dice dónde buscar, rara vez te dice la solución por sí sola, y actuar basándose en la salida de un solo comando sin corroboración es lo que empeora los incidentes.
- Temas Relacionados: Herramientas de IO y memoria, triaje de incidentes, recuperación por disco lleno.
Fundamentos
Cada sesión de triaje en un host de Postgres realmente trabaja en tres capas a la vez, incluso cuando no lo parece.
La primera capa es el sistema operativo: espacio en disco, presión de memoria y conexiones de red, todo visible a través de herramientas como df, free y ss que no saben nada de SQL.
La segunda capa es el proceso: los trabajadores postgres reales que se ejecutan en ese host, visibles a través de ps, pgrep y systemctl, que saben que existe un proceso pero no qué consulta está ejecutando.
La tercera capa es el estado de la base de datos: pg_stat_activity, pg_locks y los registros del servidor, que saben exactamente qué SQL se está ejecutando pero nada sobre la memoria libre del host.
Una analogía útil es un médico leyendo signos vitales, una radiografía y una entrevista al paciente por separado: cada capa es precisa en sus propios términos, y un diagnóstico solo es válido cuando las tres coinciden.
La disciplina central que enseña esta página es la correlación: un síntoma de disco lleno en la capa del SO y un PANIC: could not write to file en el registro de Postgres son el mismo evento visto desde dos capas, no dos problemas separados.
Aprender a moverse fluidamente entre estas tres capas, en lugar de vivir en solo una de ellas, es lo que separa el triaje rápido de las conjeturas.
Mecánica e Interacciones
La razón por la que el triaje de la CLI tiene un orden estricto (primero SO, luego proceso, luego base de datos) es que las herramientas de cada capa responden a una ventana de tiempo diferente y a un tipo de pregunta diferente.
Los comandos a nivel de SO como vmstat y iostat responden a "¿qué está sucediendo ahora mismo en este host?", independientemente de qué base de datos o consulta lo causó.
Los comandos a nivel de proceso como ps y systemctl status responden a "¿está sano el propio proceso de Postgres?", lo que importa porque un bucle de reinicio puede enmascararse como un problema de rendimiento de consultas.
Las vistas a nivel de base de datos como pg_stat_activity responden a "¿qué está haciendo Postgres ahora mismo?", incluidos los eventos de espera que explican por qué un backend es lento en lugar de solo que es lento.
La doctrina de triaje que une todo esto es simple: mide en las tres capas antes de cambiar cualquier configuración, reiniciar cualquier servicio o matar cualquier proceso, porque actuar basándose solo en la evidencia de una capa a menudo diagnostica erróneamente las otras dos.
Esta es también la razón por la que existe un script de paquete de incidentes: capturar df, free, vmstat y las instantáneas relevantes de pg_stat_activity/pg_locks juntas, en una sola pasada, antes de que algo en el sistema cambie.
# Instantánea mínima de tres capas, tomada juntas, no secuencialmente durante minutos
df -h "$PGDATA"; free -h
ps -eo pid,rss,cmd --sort=-rss | grep postgres | head -5
psql "$DATABASE_URL" -c "SELECT wait_event_type, count(*) FROM pg_stat_activity GROUP BY 1;"Capturados juntos, estos tres comandos cuentan una historia coherente; capturados con cinco minutos de diferencia durante un incidente en vivo, cada uno puede describir un momento diferente.
Consideraciones Avanzadas y Aplicaciones
La doctrina de "medir antes de tocar" se vuelve más difícil de mantener bajo la presión real de un incidente, que es precisamente cuando más importa.
Un modo de fallo común es que un operador vea alta CPU o IO y recurra directamente a un cambio de GUC o a un failover, cuando la lectura de tres capas habría mostrado un pico transitorio de checkpoint que ya se estaba resolviendo por sí solo.
La escalada a failover es una decisión a nivel de base de datos que la evidencia de la CLI puede respaldar, pero rara vez debería desencadenarla sola: fallos de hardware, corrupción o un disco irrecuperable son los tipos de hallazgos a nivel de SO que realmente lo justifican.
La distinción entre una parada elegante y un kill es donde la mecánica de la CLI se encuentra con el riesgo real: systemctl stop permite a Postgres completar su checkpoint, mientras que kill -9 en el postmaster arriesga un checkpoint incompleto y una recuperación más larga y arriesgada al próximo inicio.
El control de acceso sigue la misma lógica de capas: los comandos de SO y SQL de solo lectura son razonables para que cualquier ingeniero los ejecute, mientras que cualquier cosa que detenga un proceso o cambie una GUC pertenece detrás de una puerta de guardia o un sistema de compañeros.
A medida que la infraestructura se desplaza hacia los contenedores, el mismo modelo de tres capas sigue aplicándose dentro de una sesión de kubectl exec, simplemente reemplaza systemctl por la visibilidad del proceso del propio tiempo de ejecución del contenedor.
| Enfoque | Fortaleza | Debilidad | Mejor Ajuste |
|---|---|---|---|
Lectura de una sola capa (solo pg_stat_activity, por ejemplo) | Rápido, no requiere acceso al host | Omite por completo las causas raíz a nivel de host, como el agotamiento de disco o memoria | Comprobación rápida de cordura cuando ya confías en la salud del host |
| Correlación completa de tres capas | Detecta causas raíz que una sola capa pasaría por alto | Lleva más tiempo y requiere un acceso más amplio | Cualquier incidente real, o cualquier síntoma que no puedas explicar solo desde una capa |
| Actuar primero, medir después | Se siente rápido bajo presión | Frecuentemente diagnostica erróneamente picos transitorios como problemas reales y causa failovers innecesarios | Nunca - incluido aquí solo como el modo de fallo contra el que argumenta esta página |
Conceptos Erróneos Comunes
- "Una tormenta de consultas siempre significa un problema de base de datos" - a menudo significa que el host se quedó sin memoria o disco primero, y Postgres es solo el proceso más visiblemente afectado.
- "
kill -9es una forma rápida y segura de reiniciar un Postgres atascado" - arriesga un checkpoint incompleto, convirtiendo un reinicio lento en una recuperación más larga y arriesgada al próximo inicio. - "
pg_stat_activitysolo te dice si el host está sano" - solo sabe sobre el estado a nivel de SQL y no dice nada sobre el espacio en disco, la presión de memoria o el historial de reinicios del propio proceso. - "La CPU alta siempre significa que una consulta necesita ser optimizada" - la actividad de checkpoint, autovacuum e incluso vecinos ruidosos a nivel de host pueden producir la misma firma de CPU que un mal plan de consulta.
- "Necesitas herramientas exóticas para triar un host de Postgres" -
df,free,vmstatypsestán presentes en casi todas las imágenes de Linux y cubren la mayor parte del triaje de primer paso sin ninguna instalación adicional.
Preguntas Frecuentes
¿Cuáles son las "tres capas" a las que esta página hace referencia constantemente?
El sistema operativo (disco, memoria, red), el propio proceso de Postgres (en ejecución, reiniciándose o caído) y el estado interno de la base de datos (consultas, bloqueos, eventos de espera).
¿Por qué importa el orden SO-luego-proceso-luego-base de datos?
- El agotamiento del host puede producir síntomas que parecen específicos de la base de datos.
- Comprobar primero la capa del SO evita diagnosticar erróneamente un problema del host como un problema de consulta.
- Cada capa responde a una ventana de tiempo diferente, por lo que comprobarlas de forma aislada da una imagen incompleta.
¿Por qué capturar un paquete de incidentes en lugar de ejecutar comandos uno por uno?
Porque el estado del sistema cambia minuto a minuto durante un incidente, y los comandos ejecutados con cinco minutos de diferencia pueden estar describiendo cada uno un momento diferente en lugar de una historia coherente.
¿Cuál es la diferencia real entre una parada elegante y `kill -9`?
Una parada elegante permite a Postgres completar su checkpoint actual antes de apagarse, mientras que kill -9 interrumpe ese proceso y arriesga una recuperación más larga y arriesgada al próximo inicio.
¿Cuándo justifica un hallazgo de la CLI un failover?
Cuando apunta a algo que un reinicio no puede solucionar, como un fallo de hardware, corrupción del sistema de archivos o un disco irrecuperable, no para una tormenta de bloqueos ordinaria o un pico de IO transitorio.
¿Debería todo ingeniero tener acceso de escritura para ejecutar estos comandos en producción?
Los comandos de SO y SQL de solo lectura son razonables para la mayoría de los ingenieros, mientras que cualquier cosa que detenga un proceso o cambie la configuración debería requerir un rol de guardia o un compañero.
¿Sigue aplicándose este modelo dentro de un pod de Kubernetes?
Sí, kubectl exec te introduce en las mismas tres capas, simplemente sustituye la visibilidad del proceso del tiempo de ejecución del contenedor por systemctl.
¿Por qué la CPU alta no significa automáticamente una mala consulta?
Las escrituras de checkpoint, autovacuum y la contención a nivel de host pueden producir una firma de CPU similar, que es exactamente por qué las conclusiones de una sola capa no son fiables.
¿Qué herramientas necesita realmente un host de Postgres mínimo para el triaje?
df, free, vmstat y ps cubren la mayor parte del triaje de primer paso y están presentes en casi todas las imágenes de Linux sin instalación adicional.
¿Es alguna vez aceptable omitir el paso "medir primero" durante un incidente en vivo?
La presión para omitirlo es precisamente cuando el riesgo de diagnóstico erróneo es mayor, razón por la cual la doctrina existe como un valor predeterminado en lugar de una sugerencia.
¿Cómo se muestra un síntoma de disco lleno de manera diferente en cada capa?
En la capa del SO es df reportando 100% de uso, en la capa del proceso puede mostrarse como un bucle de reinicio, y en la capa de la base de datos aparece como un PANIC en el registro del servidor.
¿Cuál es el mayor error individual contra el que argumenta esta página?
Actuar - reiniciar, matar un proceso o realizar un failover - basándose en la evidencia de una sola capa, antes de correlacionarla con las otras dos.
Relacionado
- Fundamentos de la CLI de Linux para DBAs - los diez comandos concretos que organiza el modelo de esta página.
- Herramientas de IO y Memoria - el conjunto de herramientas de la capa del SO en profundidad.
- Habilidad de Triaje de Incidentes - una habilidad de agente construida sobre esta misma doctrina de triaje.
- Disco Lleno en PGDATA - el escenario de disco lleno del que se extrae el ejemplo de tres capas de esta página.
- Triaje de Tormentas de Bloqueos - la mitad a nivel de base de datos de una investigación de tormenta de bloqueos.
Versiones de Stack: Esta página fue escrita para PostgreSQL 18.4 ejecutándose en Linux (systemd, diseños Debian y RHEL); de lo contrario, es conceptual y no está vinculada a una versión específica de herramienta.