Accumulation de verrous en base de données
Une accumulation de verrous en base dans SysAdmin Crisis : les serveurs web semblent sains alors que la latence grimpe. Sa signature et ses distinctions.
Dernière mise à jour:
L'incident qui punit la reconnaissance de motifs. Tout, dans la baie, a l'air normal, la barre de trafic est normale, et la nuit s'effondre quand même.
Ce qu'il fait
Sur une machine de base de données, des requêtes se mettent à attendre des verrous au lieu de se terminer. Rien ne plante, aucune machine n'entre en saturation — mais les requêtes s'empilent derrière la base de données, la latence grimpe et la disponibilité la suit.
La couche web est saine de bout en bout. C'est tout le caractère de cet incident : le symptôme est une lenteur sur l'ensemble du parc de serveurs, et la cause est une unique machine qui ne passe jamais au rouge.
La signature dans les logs
Le log PostgreSQL de la machine de base de données porte les lignes d'attente et de durée, tandis qu'en périphérie n'apparaît qu'un avertissement de latence :
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 session qui détient le verrou ne rapporte que sa durée ; celles qui attendent disent qui elles attendent. On trouve la racine en remontant la chaîne de la fin vers le début. db_stat liste les requêtes actives par ID, temps d'attente et nom, et marque celles qui sont bloquées sur un verrou.
Si vous n'y touchez pas
La file des verrous s'allonge et la latence reste élevée jusqu'à la fin de la garde. Comme aucune machine ne passe à DOWN, la perte de disponibilité vient entièrement de la latence, puis de la dette de SLA. C'est pourquoi il est possible de perdre une nuit avec toute la baie au vert.
Le distinguer des autres
| Ressemble à | Ce qui les distingue |
|---|---|
| Flood DDoS | Les deux font monter la latence. Un flood fait aussi monter le CPU des machines web et provoque des avertissements SYN du noyau ; une accumulation de verrous n'en provoque aucun. |
| Tâche qui s'emballe | L'un comme l'autre peut impliquer une machine de base de données, mais une tâche qui s'emballe bloque le CPU et nomme un processus ; celui-ci nomme une requête. |
Quand il apparaît
| Première nuit | 3 |
| Nécessite | une machine db |
| Poids | 80 |
| Simultanément | une instance |
L'incident peut se clore avec un vrai coût en disponibilité ; la ligne de clôture permet de le distinguer d'une clôture propre.