이 문제는 pnpm이나 Ember의 문제라기보다는 호스트가 단순히 메모리를 다 쓴 것으로 보입니다.
핵심은 SIGKILL입니다. 이는 보통 OS가 개입하여 프로세스를 종료한 것(대부분 OOM killer에 의해)을 의미하며, ember build -prod가 자체적으로 실패한 것은 아닙니다.
작은 규모의 호스트에서는 Ember 프로덕션 빌드가 RAM 수 GB까지 급격히 증가할 수 있습니다. 스왑이 활성화되어 있더라도, 스왑이 거의 사용된 상태에서는 커널이 메모리를 많이 사용하는 node 프로세스를 종료하도록 결정할 수 있습니다.
이 방향을 가리키는 몇 가지 징후:
- 실패가 발생했을 때 스왑이 이미 많이 사용되고 있습니다.
- 다른 컨테이너가 동시에 실행 중일 때 실패 가능성이 훨씬 높습니다.
- 부트스트랩 실행 전에 다른 컨테이너를 중지하면 정확히 동일한 빌드가 성공합니다.
따라서 스왑은 다소 도움이 되지만, 대부분 문제를 단순히 지연시킬 뿐입니다. 다른 컨테이너를 중지하면 메모리 압력이 충분히 낮아져 빌드가 완료됩니다.
도움이 되거나 도움이 될 수 있는 방법:
- 여러 부트스트랩이나 에셋 빌드를 병렬로 실행하지 않도록 합니다.
ember build -prod실행 중에 다른 컨테이너를 중지합니다.- Node의 메모리 사용량을 제한하여(예:
NODE_OPTIONS=--max_old_space_size=1024) 피크 사용량을 줄입니다. - 가능하다면 호스트 RAM을 늘리면(4GB 이상) 이 문제가 훨씬 더 안정적으로 해결됩니다.
이것이 왜 다소 무작위적으로 느껴지는지, 그리고 왜 다른 컨테이너를 중지하면 작동하는지 설명하는 데 도움이 되기를 바랍니다.