GitHub indique que les récentes interruptions de service ont été causées par des problèmes de conflit de ressources dans leur cluster de base de données principal.
Depuis la semaine dernière, GitHub indique qu’il y a eu quatre interruptions de service causées par ces problèmes, les 16 mars, 17 mars, 22 mars et 23 mars.
Aujourd’hui, GitHub a expliqué que ces pannes étaient causées par des problèmes de « conflit de ressources » avec leur cluster MySQL principal appelé « MySQL1 ».
« Le thème sous-jacent de nos problèmes au cours des dernières semaines est dû à la contention des ressources dans notre cluster mysql1, qui a eu un impact sur les performances d’un grand nombre de nos services et fonctionnalités pendant les périodes de pointe de charge », explique un article de GitHub sur les pannes .
Le conflit de ressources se produit lorsque plusieurs processus/requêtes sont en concurrence pour les mêmes ressources, qu’il s’agisse de la mémoire, du processeur ou de l’utilisation du disque, ou même de l’accès à une table de base de données.
Lorsqu’il n’y a pas assez de ressources disponibles, une base de données ne sera pas en mesure de terminer les requêtes aussi rapidement, ce qui entraînera le verrouillage des tables et l’accumulation rapide des connexions à la base de données en attendant la fin des requêtes.
Au fur et à mesure que les demandes s’accumulent, le serveur atteint finalement le nombre maximal de connexions qu’il est configuré pour gérer et rejette simplement toutes les autres demandes jusqu’à ce qu’il y ait de la place pour plus.
Cela provoque l’échec de tous les services nécessitant l’accès à la base de données.
Quatre interruptions de service depuis le 16 mars
GitHub indique qu’il y a eu quatre interruptions de service causées par ces problèmes, les 16 mars, 17 mars, 22 mars et 23 mars.
Le 16 mars, GitHub a vu une charge accrue pendant les heures de pointe et des requêtes mal écrites qui ont provoqué le remplissage du nombre maximal de connexions et l’échec de toutes les opérations d’écriture dans la base de données.
« Toutes les opérations d’écriture n’ont pas pu fonctionner pendant cette panne, y compris les opérations git, les webhooks, les demandes d’extraction, les demandes d’API, les problèmes, les packages GitHub, les espaces de code GitHub, les actions GitHub et les services de pages GitHub », explique le GitHub. article de blog.
La panne suivante a eu lieu le 17 mars, où ils ont constaté des problèmes similaires avant de pouvoir résoudre les mauvaises performances des requêtes. Après avoir basculé sur d’autres serveurs, ils ont de nouveau rapidement atteint leur maximum de connexions.
Le 22 mars, GitHub a déclaré que bien qu’ils aient appliqué des atténuations aux performances des requêtes, ils continuaient à les analyser et activaient le profilage de la mémoire sur leur proxy de base de données. Cela a permis une fois de plus d’atteindre le maximum de connexions.
Enfin, hier, le 23 mars, ils ont de nouveau constaté une augmentation de la charge entraînant l’échec des connexions client. Pour résoudre ces problèmes, GitHub a décidé de limiter le trafic du webhook afin de réduire la charge sur ses serveurs.
Pour éviter ces types de pannes à l’avenir, GitHub déclare qu’ils auditent leurs systèmes pendant les heures de pointe et créeront des correctifs de performances en fonction des résultats.
Ils redirigent également le trafic vers d’autres bases de données pour réduire la charge et augmentent l’infrastructure et le partage pour augmenter les performances.
Le partage de base de données se produit lorsque de grandes tables de base de données sont divisées en plusieurs tables qui peuvent ensuite être stockées sur plusieurs serveurs. En divisant une grande base de données très utilisée en plusieurs bases de données plus petites sur différents serveurs, cela peut augmenter les performances et empêcher les requêtes intensives de verrouiller la table.
GitHub déclare qu’ils partageront des informations plus détaillées lors de leur prochain Rapport de disponibilité sur ce qu’ils font pour prévenir ces types de pannes à l’avenir.