ID de la causa db-deadlock · Responsable principal Desarrollo de servidor (Equipo de desarrollo) · También Infraestructura de BD (Equipo de infraestructura)
Si dos transacciones (operaciones de BD que se procesan como un solo bloque) esperan cada una la fila que bloqueó la otra, la BD cancela una de ellas a la fuerza.
Por qué El intercambio A bloquea en el orden objeto→moneda y el B en el orden moneda→objeto → Efecto La BD detecta el deadlock y hace rollback de una de las dos → En pantalla Intercambios y fabricaciones que fallan de vez en cuando, objetos que se revierten
Cuando se junta mucha gente, Al hacer ciertas acciones
Responsable
Responsable principal Desarrollo de servidor (Equipo de desarrollo) · También Infraestructura de BD (Equipo de infraestructura)
Tareas (Equipo de desarrollo)
Unificar el orden de los bloqueos, acortar las transacciones, reintentar automáticamente si fallan.
Tareas (Equipo de infraestructura)
Mantener activada la detección de deadlocks, recoger los registros de deadlocks y compartirlos, reducir el límite de espera de bloqueo (50 segundos por defecto) en los servidores MySQL con la detección desactivada.
Cifras de referencia
El tiempo hasta detectarlo es casi inmediato en MySQL (InnoDB), de 1 segundo por defecto en PostgreSQL y de hasta unos 5 segundos en SQL Server. Mientras tanto, las dos solicitudes están detenidas. En un servidor MySQL con la detección desactivada por tener muchísimas solicitudes simultáneas, la espera llega hasta el límite de espera de bloqueo (50 segundos por defecto).
En el gráfico
Picos aleatorios · Número de deadlocks, número de intercambios fallidos
Dónde mirar
En MySQL, LATEST DETECTED DEADLOCK de SHOW ENGINE INNODB STATUS (solo el más reciente), todos los deadlocks que quedan en el log de errores con innodb_print_all_deadlocks activado y lock_deadlocks de INFORMATION_SCHEMA.INNODB_METRICS. En PostgreSQL, deadlocks de pg_stat_database; en SQL Server, xml_deadlock_report de la sesión system_health, activa por defecto. Códigos de error en el servidor del juego: MySQL 1213, PostgreSQL 40P01, SQL Server 1205
Se confirma si
Cuando fallan los intercambios o las fabricaciones, el número de deadlocks sube, y las dos transacciones registradas bloquean las mismas tablas en orden inverso
Se descarta si
Si fallan pero el número de deadlocks no cambia, apunta a un límite de espera de bloqueo superado (error 1205 de MySQL) o a una fila caliente (db-hot-row)
Se verifica con
Con herramientas de infraestructura (no hace falta código del juego)
Fuentes
InnoDB Startup Options and System VariablesMySQL Con la detección activada (por defecto), InnoDB detecta los deadlocks al instante y hace rollback; innodb_lock_wait_timeout es de 50 s por defecto
Deadlock DetectionMySQL Con concurrencia muy alta, la propia detección puede volverse lenta, y a veces se desactiva para dejarlo en manos del límite de espera de bloqueo
Deadlocks guideMicrosoft SQL Server Intervalo de detección de deadlocks de 5 s por defecto, que baja hasta 100 ms si los deadlocks son frecuentes; la sesión system_health, activa por defecto, recoge xml_deadlock_report; la transacción elegida como víctima recibe el error 1205
How to Minimize and Handle DeadlocksMySQL Modificar siempre varias filas o tablas en el mismo orden, reintentar si falla, registrar todos los deadlocks con innodb_print_all_deadlocks
InnoDB Standard Monitor and Lock Monitor OutputMySQL LATEST DETECTED DEADLOCK: las dos transacciones del deadlock más reciente, los bloqueos que tenían y los que esperaban, y la que recibió el rollback