Acúmulo de locks no banco de dados
Acúmulo de locks no SysAdmin Crisis: os servidores web parecem saudáveis enquanto a latência sobe. Veja a assinatura nos logs e como distingui-lo.
Última atualização:
O incidente que pune quem decide por reconhecimento de padrões. Tudo no rack parece bem, a barra de tráfego está normal, e a noite desmorona mesmo assim.
O que ele faz
Em uma máquina de banco de dados, as consultas começam a esperar por locks em vez de terminar. Nada trava, nenhuma máquina entra em saturação — mas as requisições se enfileiram atrás do banco de dados, a latência sobe e a disponibilidade (uptime) vai atrás.
A camada web fica saudável de ponta a ponta. Esse é todo o caráter deste incidente: o sintoma é lentidão na frota inteira, e a causa é uma única máquina que nunca fica vermelha.
A assinatura nos logs
O log do PostgreSQL da máquina de banco de dados traz as linhas de espera e duração, enquanto na borda só aparece um aviso de latência:
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
A sessão que segura o lock apenas informa sua duração; as que esperam dizem por quem estão esperando. Você encontra a raiz percorrendo a cadeia do fim até o começo. db_stat lista as consultas ativas por ID, tempo de espera e nome, e marca as que estão presas em um lock.
Se você deixar de lado
A fila de locks cresce e a latência fica alta pelo resto do turno. Como nenhuma máquina fica DOWN, a perda de disponibilidade vem inteiramente da latência e, depois, da dívida de SLA. Por isso é possível perder uma noite com o rack inteiro verde.
Como distingui-lo
| Parece com | O que o separa |
|---|---|
| Inundação de DDoS | Ambos elevam a latência. Uma inundação também eleva a CPU das máquinas web e traz avisos de SYN do kernel; um acúmulo de locks não traz nenhuma das duas coisas. |
| Tarefa descontrolada | Qualquer um dos dois pode envolver uma máquina de banco de dados, mas uma tarefa descontrolada trava a CPU e nomeia um processo; este nomeia uma consulta. |
Quando ele aparece
| Noite mínima | 3 |
| Requer | uma máquina db |
| Peso | 80 |
| Ao mesmo tempo | uma instância |
O incidente pode terminar com um custo real de disponibilidade; a linha de fechamento é o que distingue isso de um fechamento limpo.