Datenbank-Sperrstau
Ein Datenbank-Sperrstau in SysAdmin Crisis: Die Webserver wirken gesund, während die Latenz steigt. Lerne die Log-Signatur und die Abgrenzung.
Zuletzt aktualisiert:
Der Vorfall, der Mustererkennung bestraft. Im Rack sieht alles gut aus, der Traffic-Balken ist normal, und die Nacht fällt trotzdem auseinander.
Was er tut
Auf einer Datenbankmaschine warten Abfragen auf Sperren, statt fertig zu werden. Nichts stürzt ab, keine Maschine gerät in die Sättigung – aber Anfragen stauen sich hinter der Datenbank, die Latenz steigt, und die Verfügbarkeit (Uptime) folgt ihr.
Das Web-Tier ist von Ende zu Ende gesund. Das ist der ganze Charakter dieses Vorfalls: Das Symptom ist Langsamkeit im gesamten Serverpark, und die Ursache ist eine einzelne Maschine, die nie rot wird.
Die Log-Signatur
Das PostgreSQL-Log der Datenbankmaschine enthält die Warte- und Dauerzeilen, während am Rand nur eine Latenzwarnung auftaucht:
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
Die Sitzung, die die Sperre hält, meldet nur ihre Dauer; die wartenden sagen, auf wen sie warten. Die Wurzel findest du, indem du die Kette vom Ende zum Anfang zurückverfolgst. db_stat listet aktive Abfragen nach ID, Wartezeit und Name auf und markiert diejenigen, die an einer Sperre hängen.
Wenn du ihn in Ruhe lässt
Die Sperrwarteschlange wächst, und die Latenz bleibt für den Rest der Schicht hoch. Da keine Maschine auf DOWN geht, kommt der Verlust an Verfügbarkeit ganz aus der Latenz und dann aus der SLA-Schuld. Deshalb ist es möglich, eine Nacht zu verlieren, obwohl das ganze Rack grün ist.
Abgrenzung
| Sieht ähnlich aus | Was unterscheidet |
|---|---|
| DDoS-Flut | Beide erhöhen die Latenz. Eine Flut erhöht außerdem die CPU der Webmaschinen und bringt SYN-Warnungen vom Kernel; ein Sperrstau bringt keins von beidem. |
| Runaway-Job | Beide können eine Datenbankmaschine betreffen, aber ein Runaway-Job blockiert die CPU und nennt einen Prozess; dieser Vorfall nennt eine Abfrage. |
Wann er auftaucht
| Früheste Nacht | 3 |
| Voraussetzung | eine db-Maschine |
| Gewicht | 80 |
| Gleichzeitig | eine Instanz |
Der Vorfall kann mit echten Kosten für die Verfügbarkeit enden; die Schlusszeile verrät, wie du das von einem sauberen Abschluss unterscheidest.