Após quatro interrupções de serviço, finalmente o GitHub explicou o que causou as interrupções da semana passada.
O GitHub diz que as interrupções de serviço recentes foram causadas por problemas de contenção de recursos em seu cluster de banco de dados primário.
GitHub explicou o que causou as interrupções da semana passada
Desde a semana passada, o GitHub diz que houve quatro interrupções de serviço causadas por esses problemas, em 16 de março, 17 de março, 22 de março e 23 de março.
Agora, o GitHub explicou que essas interrupções foram causadas por problemas de “contenção de recursos” com seu cluster MySQL primário chamado ‘MySQL1’.
“O tema subjacente de nossos problemas nas últimas semanas foi devido à contenção de recursos em nosso cluster mysql1, que afetou o desempenho de um grande número de nossos serviços e recursos durante os períodos de pico de carga.”, explica uma postagem do GitHub sobre as interrupções.
A contenção de recursos ocorre quando vários processos/solicitações competem pelos mesmos recursos, seja memória, CPU ou utilização de disco, ou mesmo acesso a uma tabela de banco de dados.
Quando não há recursos suficientes disponíveis, um banco de dados não poderá concluir as consultas tão rapidamente, fazendo com que as tabelas sejam bloqueadas e as conexões de banco de dados se acumulem rapidamente enquanto aguardam a conclusão das consultas.
À medida que as solicitações se acumulam, o servidor finalmente atinge o número máximo de conexões que está configurado para lidar e simplesmente rejeita todas as solicitações adicionais até que haja espaço para mais.
Isso faz com que todos os serviços que exigem acesso ao banco de dados falhem.
O GitHub diz que houve quatro interrupções de serviço causadas por esses problemas, em 16 de março, 17 de março, 22 de março e 23 de março.
Em 16 de março, o GitHub viu um aumento de carga durante os horários de pico e consultas mal escritas que fizeram com que o máximo de conexões ficasse cheio e todas as operações de gravação no banco de dados falhassem.
“Todas as operações de gravação não funcionaram durante essa interrupção, incluindo operações git, webhooks, pull requests, solicitações de API, problemas, GitHub Packages, GitHub Codespaces, GitHub Actions e GitHub Pages services”, explica a postagem do blog do GitHub.
A próxima interrupção foi em 17 de março, quando eles viram problemas semelhantes antes que pudessem resolver o baixo desempenho da consulta. Depois de fazer failover para outros servidores, eles mais uma vez atingiram rapidamente suas conexões máximas.
Em 22 de março, o GitHub disse que, embora tenham aplicado mitigações ao desempenho de consultas, eles continuaram a analisá-las e habilitaram o perfil de memória em seu proxy de banco de dados. Isso mais uma vez levou a que o máximo de conexões fosse alcançado.
Finalmente, ontem, 23 de março, eles mais uma vez viram o aumento da carga fazendo com que as conexões dos clientes falhem. Para resolver esses problemas, o GitHub decidiu limitar o tráfego do webhook para reduzir a carga em seus servidores.
Para evitar esses tipos de interrupções no futuro, o GitHub afirma que está auditando seus sistemas durante os horários de pico e criará correções de desempenho com base nos resultados.
Eles também estão redirecionando o tráfego para outro banco de dados para reduzir a carga e aumentar a infraestrutura e o sharding para aumentar o desempenho.
A fragmentação de banco de dados ocorre quando grandes tabelas de banco de dados são divididas em várias tabelas que podem ser armazenadas em vários servidores. Ao fragmentar um banco de dados grande e altamente usado em vários bancos de dados menores em servidores diferentes, ele pode aumentar o desempenho e impedir que consultas intensivas bloqueiem a tabela.
O GitHub afirma que eles compartilharão informações mais detalhadas em seu próximo Relatório de Disponibilidade sobre o que estão fazendo para evitar esses tipos de interrupções no futuro.
