Já tive travamentos 4x de servidores AWS ERP devido à memória aparentemente esgotada e o sistema essencialmente morrendo com 100% de CPU e nenhuma [pouca] RAM disponível.
Ubuntu 18.04.5 LTS (GNU/Linux 5.4.0-1060-aws x86_64) (AWS AMI)
Isso ocorreu três vezes no meio de uma ação do GitHub. A ação foi fazer uma importação de banco de dados e, em seguida, uma notificação de folga. Portanto, você pensaria que foi uma dessas etapas que causou o problema, mas estranhamente todas as etapas foram concluídas normalmente. O banco de dados estava bom e a notificação de folga foi enviada.
O próprio GitHub perdeu a conexão com o executor e a memória virtual disparou mesmo depois que a ação foi concluída.
Pela quarta vez, isso aconteceu enquanto NADA estava em execução. Na verdade, o servidor estava ocioso, sem nada acontecendo. No entanto, não tenho nenhum registro ou captura de tela "principal" DISSO, mas peguei em flagrante uma vez:
Portanto, o sistema é uma VM AWS com 4G de RAM. Observe que acredito que o SI que configurou este sistema não configurou espaço de troca. Isso é indiscutivelmente correto [muito indiscutivelmente] para um servidor, no sentido de que, se houver um vazamento de memória, você deseja que o sistema relate falta de memória e tome medidas corretivas, pois com um vazamento de memória você acabará morrendo de qualquer maneira.
No curto prazo, pediram-me apenas para duplicar a RAM. Isso é um tanto desnecessário, pois é um sistema com carga leve (normalmente roda com apenas cerca de 2G de RAM em uso ao fazer um trabalho em lote pesado) e, francamente, se o GitHub Runner.Worker atinge o máximo de 7 GB de RAM em um sistema de 4 GB, por que não atingiria o máximo de 16 GB de RAM em uma VM de 8 GB, mas veremos se ele trava novamente. Não tenho aversão a alterar a configuração de swap do TFG, mas não tenho certeza se isso é uma solução
Eu relatei isso ao GitHub, mas depois de três semanas de inação, pensei em verificar aqui e ver se alguém tem alguma idéia ou solução.
Obrigado,
== João ==