Acumulación de bloqueos en la base de datos
Una acumulación de bloqueos en la base de datos de SysAdmin Crisis: los servidores web parecen sanos mientras sube la latencia. Aprende su firma.
Última actualización:
El incidente que castiga el reconocimiento de patrones. Todo en el rack parece estar bien, la barra de tráfico es normal, y la noche se desmorona de todos modos.
Qué hace
En una máquina de base de datos, las consultas empiezan a esperar bloqueos en lugar de terminar. Nada se cae, ninguna máquina entra en saturación, pero las solicitudes se encolan detrás de la base de datos, la latencia sube y la disponibilidad la sigue.
La capa web está sana de extremo a extremo. Ese es todo el carácter de este incidente: el síntoma es la lentitud en toda la flota, y la causa es una única máquina que nunca se pone en rojo.
La firma en el log
El log de PostgreSQL de la máquina de base de datos lleva las líneas de espera y de duración, mientras que en el borde solo aparece una advertencia de latencia:
04:03:11 db-01 postgres[1187]: [2210] LOG: process 2210 still waiting for ShareLock on transaction 48212 after 1000.051 ms
04:03:11 db-01 postgres[1187]: [2210] DETAIL: Process holding the lock: 2207. Wait queue: 2210.
04:03:40 web-01 monit[598]: 'shop-api' failed protocol test [HTTP] at [localhost]:80/healthz [TCP/IP] -- HTTP: response time 2100 ms exceeds 1000 ms
04:04:12 db-01 postgres[1187]: [1187] FATAL: remaining connection slots are reserved for non-replication superuser connections
La sesión que mantiene el bloqueo solo informa de su duración; las que esperan dicen a quién esperan. La raíz se encuentra recorriendo la cadena del final al principio. db_stat enumera las consultas activas por ID, tiempo de espera y nombre, y marca las que están atascadas en un bloqueo.
Si lo dejas
La cola de bloqueos crece y la latencia se mantiene alta el resto del turno. Como ninguna máquina pasa a DOWN, la pérdida de disponibilidad proviene por completo de la latencia y luego de la deuda de SLA. Por eso es posible perder una noche con todo el rack en verde.
Cómo distinguirlo
| Se parece a | Qué lo distingue |
|---|---|
| Inundación DDoS | Ambas elevan la latencia. Una inundación también eleva la CPU de las máquinas web y trae advertencias SYN del kernel; una acumulación de bloqueos no trae ninguna de las dos. |
| Tarea descontrolada | Cualquiera de las dos puede involucrar una máquina de base de datos, pero una tarea descontrolada acapara la CPU y nombra un proceso; esta nombra una consulta. |
Cuándo aparece
| Noche más temprana | 3 |
| Necesita | una máquina db |
| Peso | 80 |
| A la vez | una instancia |
El incidente puede cerrarse con un costo real de disponibilidad; la línea de cierre es lo que lo distingue de un cierre limpio.