한국어English日本語简体中文繁體中文DeutschไทยTiếng ViệtРусскийPortuguês (Brasil)EspañolBahasa Indonesia

Game-Lag-Whitepaper › L12 Datenbank

Hot-Row-Lock-Contention Hot row lock contention

Ursachen-ID db-hot-row · Hauptzuständig Server-Entwicklung (Entwicklungsteam) · Beteiligt DB-Infrastruktur (Infrastrukturteam)

In der interaktiven Fassung mit Grafiken und Experimenten öffnen →

Wollen alle dieselbe Zeile ändern (Gildenlager, begehrtes Item im Auktionshaus, serverweiter Zähler), bekommt immer nur einer den Lock.

Warum Durch ein Event oder ein begehrtes Item häufen sich Änderungen an derselben Zeile → Folge Anfragen warten, bis sie den Lock bekommen → Auf dem Bildschirm Handel schlägt fehl, „Bitte später erneut versuchen“, Timeouts

Symptome
Verschluckte Aktion / Rollback, Input-Lag
Faktoren
Stillstand, Latenz
Wer ist betroffen
Nur eine bestimmte Funktion
Wann
Bei großem Andrang
Zuständigkeit
Hauptzuständig Server-Entwicklung (Entwicklungsteam) · Beteiligt DB-Infrastruktur (Infrastrukturteam)
Aufgaben Entwicklungsteam
Zeile aufteilen (Sharded Counter), Transaktionen kurz halten, Änderungen im Speicher sammeln und gebündelt schreiben.
Aufgaben Infrastrukturteam
Wartezeit und Anzahl der Wartevorgänge auf Zeilensperren überwachen, Zeilen mit gehäufter Contention ermitteln und weitergeben.
Größenordnungen
Hält eine Anfrage den Lock 10 ms lang, lässt sich die Zeile höchstens 100-mal pro Sekunde ändern. Enthält die Transaktion zusätzlich einen Round Trip zu einem anderen Server, sinkt dieser Wert entsprechend weiter.
Im Graphen
Steigt mit Spielerzahl und Last · Wartevorgänge auf Zeilensperren (Anzahl, Dauer)
Wo nachsehen
MySQL: Zuwachs von Innodb_row_lock_waits und Innodb_row_lock_time sowie Innodb_row_lock_current_waits prüfen, mit sys.innodb_lock_waits ermitteln, wer auf wen wartet. PostgreSQL: Sessions mit wait_event_type Lock in pg_stat_activity und Anfragen mit granted = false in pg_locks prüfen; mit log_lock_waits (standardmäßig aus) landen lange Lock-Wartezeiten im Log
Spricht dafür
Lock-Wartevorgänge steigen mit Event und Spielerzahl steil an, die meisten wartenden Anfragen zielen auf dieselbe Zeile (denselben Schlüssel) derselben Tabelle
Spricht dagegen
Wartevorgänge gleichmäßig auf viele Tabellen und Zeilen verteilt: eher ausgelasteter Datenträger oder ausgelastete CPU. Eine Session hält einen Lock lange und gibt ihn nicht frei: lange offene Transaktion (db-long-tx)
Prüfmittel
Mit Infrastruktur-Tools prüfbar (ohne Spielcode)

Quellen

  1. InnoDB Locking MySQL
    Sperrt eine Transaktion eine Zeile (einen Indexeintrag), kann keine andere Transaktion diese Zeile ändern und muss warten
  2. How to Minimize and Handle Deadlocks MySQL
    Empfehlung, Transaktionen klein und kurz zu halten und direkt nach zusammengehörigen Änderungen zu committen, um Konflikte zu verringern
  3. Server Status Variables MySQL
    Innodb_row_lock_waits und Innodb_row_lock_time liefern Anzahl und Dauer der Wartevorgänge auf Zeilensperren, Innodb_row_lock_current_waits die Zahl der aktuell Wartenden
  4. The innodb_lock_waits and x$innodb_lock_waits Views MySQL
    Wartende Query (waiting_query), blockierende Session (blocking_pid), Wartezeit (wait_age)
  5. The Cumulative Statistics System (PostgreSQL Documentation) PostgreSQL
    wait_event_type in pg_stat_activity: Lock bedeutet, dass auf einen Heavyweight-Lock gewartet wird
  6. pg_locks (PostgreSQL Documentation) PostgreSQL
    granted = false: Der Prozess wartet darauf, den Lock zu bekommen
  7. Error Reporting and Logging (PostgreSQL Documentation) PostgreSQL
    log_lock_waits: schreibt einen Logeintrag, wenn länger als deadlock_timeout auf einen Lock gewartet wird, standardmäßig aus

Verwandte Ursachen

Gleiche Schicht: L12 Datenbank

Ursachen aus anderen Schichten mit demselben Symptom (Verschluckte Aktion / Rollback)

Karte in der interaktiven Fassung mit Grafiken und Experimenten ansehen