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.