De 288 deadlocks par mois à environ quatre
Read Committed Snapshot Isolation et la refonte des pires transactions, mais ce qui a tout rendu possible, c’est d’avoir d’abord capturé correctement les deadlocks.
01Le problème
La fin de mois était la pire période. La plateforme enregistrait 288 deadlocks par mois, dont 53 sur la pire journée. Les transferts échouaient avec des erreurs qui ne disaient rien au caissier, le support les relançait à la main, et personne ne pouvait dire quelles transactions entraient en collision, faute de capture.
02Ce que j’ai fait
J’ai mis en place une session Extended Events pour enregistrer chaque graphe de deadlock en production. J’ai obtenu ainsi une liste classée de ce qui entrait réellement en collision, une meilleure base de décision que n’importe quelle théorie. Deux changements en sont sortis. La base est passée en Read Committed Snapshot Isolation pour que les lectures cessent de bloquer les écritures, et les transactions en tête de liste ont été refaites.
03Le résultat
Environ quatre deadlocks par mois, contre 288. La capture tourne toujours en production et alerte quelqu’un quand un nouveau schéma apparaît, de sorte que la prochaine régression se voit en quelques jours plutôt qu’à la prochaine clôture de fin de mois.
04Preuves
Captures Extended Events d’avant et d’après. L’alerte est toujours active.
Demandez-les en visio et j’ouvrirai le tableau de bord.