Em 11 de agosto de 2015 18:35, Sergio Oliveira escreveu:
> Relatando o problema que encontramos, como atuamos pra resolver > paliativamente e > e como vamos proceder para obter uma solução definitiva. > > Raiz da causa do problema: o script de importação de dados que é executado > a cada minuto deveria algum tipo de trava para prevenir que mais de uma > instancia dele seja executada simultaneamente. Por não possuir esta trava > vários processos estavam sendo executados, cada um com uma conexão aberta > com o banco de dados do colab. Quando esse número aumentava acima de um > determinado limite, o limite de conexões por usuário no banco de dados > era atingido. Durante este espaço de tempo, qualquer requisição recebida > que envolvesse acesso ao banco de dados do colab (todas, no caso de > usuários > logados, e uma boa parte, no caso de usuários não logados) iria retornar um > "erro interno no servidor" (erro 500). > > Para identificar o problema analisamos os processos em execução na máquina > e > correlacionamos com os logs do colab. O número anormal de processos nos > deu > a dica de que o problema poderia estar relacionado com algum limite sendo > exaurido e ao analisar os logs do colab encontramos erros informando que o > limite de conexões com o PostgreSQL havia sido atingido. O limite de > conexões > com o banco não era a causa mas apenas um sintoma do problema e aumentar > as conexões serviria apenas como paliativo, por isso a importância da > analise > de logs dentro de um contexto. > > Analisando os logs, notamos que de fato este erro, que era identificado > como > "OperationalError" predominava em relação aos outros: > > $ grep '^\w*Error:' colab.log | awk '{print $1}' | sort | uniq -c > 37 AttributeError: > 37 IntegrityError: > 81 KeyError: > 26 LocationValueError: > 6 MaxRetryError: > 17237 OperationalError: > 45 SerialisationError: > 12 TemplateSyntaxError: > 2526 TypeError: > 2786 UnicodeDecodeError: > 488 XMLSyntaxError: > > Além disso, também foi possível identificar com que frequência este erro > acontecia > desde quando ele ocorreu pela primeira vez até o final dos logs que > tínhamos disponíveis > para análise: > > $ grep -A 2 remaining.*connection colab.log | grep 2015 | cut -d ' ' -f 1 > | sort | uniq -c > 1807 2015-07-25 > 221 2015-07-28 > 4691 2015-07-29 > 4735 2015-07-30 > 2114 2015-08-01 > 2868 2015-08-02 > 801 2015-08-03 > > A solução temporária foi desabilitar a tarefa agendada enquanto a correção > não > for implementada. Com isso os dados do Gitlab deixarão de ser importados > temporariamente. Além disso os logs de erro do Colab serão enviados para um > servidor mantido por nós enquanto o servidor de monitoramento não estiver > pronto. > > A solução definitiva será implementar uma trava do tipo lock na importação > de dados. >
Obrigado Sergio (e Terceiro) pelo relato. Estou copiando a lista para que todos da equipe de desenvolvimento possam ler e possamos aprender.
Vamos ver com MP para tirarmos boas lições disso, de ambos os lados.
Paulo Meireles