A compilação está buscando/usando ativos pré-compilados? Ou você desativou isso? (ou aplicou um patch no núcleo de modo que os ativos pré-compilados não possam ser usados)
Você tem muita memória swap, mas uma grande parte já está em uso. Como uma configuração de dois contêineres tem menos tempo de inatividade, talvez seja verdade que a invocação atual do servidor ainda esteja em execução e tenha acumulado muito uso de memória, talvez devido a um vazamento.
Talvez uma reinicialização ajude, antes da atualização. Talvez meça o uso da swap antes e depois da reinicialização.
Estou com algum tipo de vazamento/expansão de memória em um dos meus servidores. Por sugestão sensata de @RGJ, agendei um reboot via cron toda segunda-feira de manhã (Horário da Europa Ocidental) a cada 7 dias.
(Acreditamos saber qual plugin está com o problema, mas não investi tempo para descobrir por que há um vazamento/expansão de memória)
Isto parece ser um OOM kill (falha por falta de memória): Estou com cerca de 2 GiB de RAM e em reconstruções de dois contêineres, o aplicativo antigo + a nova compilação se sobrepõem, excedendo a memória. A swap já está com cerca de 3 GiB usados antes da inicialização, então o pico da compilação do Ember recebe um SIGKILL. Parar o contêiner em execução (ou fazer uma reconstrução de um contêiner) evita a sobreposição e é bem-sucedido. O próximo passo é confirmar via dmesg e então reiniciar antes das reconstruções / investigar o que está aumentando a swap com o tempo / adicionar RAM (a swap sozinha não parece salvá-la quando já está muito utilizada).
Isto parece menos um problema do pnpm ou do Ember e mais com o host simplesmente ficando sem memória.
O detalhe chave é o SIGKILL. Isso geralmente significa que o sistema operacional interveio e encerrou o processo (muitas vezes via OOM killer), e não que o ember build -prod falhou por conta própria.
Em hosts pequenos, as compilações de produção do Ember podem facilmente atingir picos de alguns GB de RAM. Mesmo com a memória de troca (swap) ativada, uma vez que a memória de troca esteja quase totalmente usada, o kernel ainda pode decidir encerrar um processo node que consome muita memória.
Algumas coisas que apontam nessa direção:
A memória de troca já está sendo muito utilizada quando a falha ocorre.
A falha é muito mais provável quando outro contêiner está sendo executado ao mesmo tempo.
Se eu parar o outro contêiner antes de executar o bootstrap, a mesma compilação é bem-sucedida.
Portanto, a memória de troca ajuda um pouco, mas principalmente apenas adia o problema. Parar outros contêineres reduz a pressão de memória o suficiente para a compilação terminar.
O que ajudou / pode ajudar:
Evitar executar vários bootstraps ou compilações de ativos em paralelo.
Parar outros contêineres durante o ember build -prod.
Limitar o uso de memória do Node (por exemplo, NODE_OPTIONS=--max_old_space_size=1024) para reduzir o uso de pico.
Se possível, aumentar a RAM do host (4GB+) torna isso muito mais confiável.
Espero que isso ajude a explicar por que parece um pouco aleatório e por que parar outro contêiner faz funcionar.
Parece que mais swap ajudaria. Não faria mal. Em vez de olhar para o swap total e dizer que parece muito, olhe para o swap livre e certifique-se de ter margem para uma reconstrução.
Parece uma boa ideia! Você reinicia o servidor ou apenas o contêiner?
De qualquer forma, aconteceu novamente em outro servidor de 2GB+3GB. Então eu reiniciei o web_only e tentei novamente e funcionou perfeitamente. Acho que vou adicionar à minha ferramenta o reinício do web_only, talvez se a memória estiver em alguma definição de “baixa”.
Vimos um caso em que reiniciar o Linux ajudou. Eu sei que normalmente não é assim que gostamos de ver o Linux, mas ainda existe a possibilidade de fragmentação e a possibilidade de vazamentos de memória.
