Uso de memória do build do Ember-cli arrisca falha (OOM) no tamanho mínimo da instância

Parece que aumentamos explicitamente a memória heap permitida do Node de 500M para 2G - possivelmente isso é um exagero e 1,5G seria melhor:

Vale a pena notar que Ember não é a única coisa rodando na máquina, e estamos atingindo o limite global de RAM + swap. Portanto, o histórico da máquina e as necessidades de todos os outros processos em execução entram em jogo. Meu reinício pode ter ajudado aqui a atingir uma marca d’água mais baixa em comparação com ontem.

O pull request acima foi referenciado em
Falha ao atualizar a instância do Discourse para 15 de fevereiro de 2022
onde também observamos que alguém teve falta de memória que foi resolvida com um reinício.

É lamentável que o comando time não relate o uso máximo de memória. Possivelmente, em uma máquina com pelo menos 3G de RAM e sem swap, a contagem RSS nos diria o pico de uso da Ember. Ou possivelmente poderíamos usar outra tática - várias são descritas aqui e há algumas ideias aqui também.

O que é complicado é que realmente estamos interessados no uso de memória aqui, enquanto em muitos casos as pessoas estão interessadas no uso de RAM, que é uma questão diferente.

3 curtidas