Warten zwei Transaktionen (DB-Operationen, die als ein Paket verarbeitet werden) jeweils auf eine Zeile, die die andere gesperrt hat, bricht die DB eine davon zwangsweise ab.
Warum Handel A sperrt in der Reihenfolge Item → Währung, Handel B in der Reihenfolge Währung → Item → Folge Die DB erkennt den Deadlock und rollt eine der beiden Transaktionen zurück → Auf dem Bildschirm Handel und Crafting schlagen gelegentlich fehl, Items werden zurückgebucht
Einheitliche Lock-Reihenfolge festlegen, Transaktionen kurz halten, bei Fehlschlag automatisch wiederholen.
Aufgaben Infrastrukturteam
Deadlock-Erkennung eingeschaltet lassen, Deadlock-Protokolle sammeln und weitergeben, auf MySQL-Servern mit abgeschalteter Erkennung das Lock-Wait-Timeout (Standard 50 s) verkürzen.
Größenordnungen
Bis zur Erkennung vergeht bei MySQL (InnoDB) kaum Zeit, bei PostgreSQL standardmäßig 1 s, bei SQL Server bis zu etwa 5 s. So lange stehen beide Anfragen still. Hat ein MySQL-Server die Erkennung wegen sehr vieler gleichzeitiger Anfragen abgeschaltet, wird bis zum Lock-Wait-Timeout gewartet (Standard 50 s).
Im Graphen
Vereinzelte Spitzen ohne Muster · Anzahl der Deadlocks, fehlgeschlagene Handelsvorgänge
Wo nachsehen
MySQL: LATEST DETECTED DEADLOCK in SHOW ENGINE INNODB STATUS (nur der jüngste Fall), bei aktiviertem innodb_print_all_deadlocks alle Deadlocks im Error-Log sowie lock_deadlocks in INFORMATION_SCHEMA.INNODB_METRICS prüfen. PostgreSQL: deadlocks in pg_stat_database prüfen, SQL Server: xml_deadlock_report der standardmäßig aktiven Session system_health prüfen. Fehlercodes auf Seite des Spielservers: MySQL 1213, PostgreSQL 40P01, SQL Server 1205
Spricht dafür
Zu den Zeitpunkten fehlgeschlagener Handels- oder Crafting-Vorgänge steigt die Zahl der Deadlocks, und die beiden protokollierten Transaktionen sperren dieselben Tabellen in umgekehrter Reihenfolge
Spricht dagegen
Deadlock-Zahl unverändert, trotzdem Fehlschläge: Lock-Wait-Timeout überschritten (MySQL-Fehler 1205) oder Hot Row (db-hot-row)
Prüfmittel
Mit Infrastruktur-Tools prüfbar (ohne Spielcode)
Quellen
InnoDB Startup Options and System VariablesMySQL Bei aktivierter Erkennung (Standard) erkennt InnoDB Deadlocks sofort und führt ein Rollback aus, innodb_lock_wait_timeout Standard 50 s
Deadlock DetectionMySQL Bei sehr hoher Parallelität kann die Erkennung selbst bremsen; dann wird sie mitunter abgeschaltet und das Lock-Wait-Timeout übernimmt
Deadlocks guideMicrosoft SQL Server Standardintervall der Deadlock-Prüfung 5 s, bei häufigen Deadlocks sinkt es bis auf 100 ms; die standardmäßig aktive Session system_health erfasst xml_deadlock_report; die als Opfer gewählte Seite erhält Fehler 1205
How to Minimize and Handle DeadlocksMySQL Mehrere Zeilen und Tabellen immer in derselben Reihenfolge ändern, bei Fehlschlag wiederholen, mit innodb_print_all_deadlocks alle Deadlocks protokollieren