오늘 여러 2-컨테이너 부트스트랩이 다음과 같은 오류로 실패했습니다:
ERR_PNPM_RECURSIVE_EXEC_FIRST_FAIL Command was killed with SIGKILL (Forced termination): ember build -prod"]
스왑을 추가한 후 다음 시도에서는 작동한 것 같습니다. 하지만 이 환경에는 4GB의 스왑이 있습니다:
# free -h
total used free shared buff/cache available
Mem: 1.9Gi 1.1Gi 391Mi 45Mi 661Mi 830Mi
Swap: 4.0Gi 3.1Gi 911Mi
그럼에도 여전히 실패합니다. 그리고 부트스트랩 전에 컨테이너를 중지하면 성공합니다.
빌드가 사전 구축된 자산을 가져오거나 사용하나요? 아니면 해당 기능을 비활성화했나요? (또는 사전 구축된 자산을 사용할 수 없도록 코어를 패치했나요)
스와프 공간이 많이 남아 있지만, 상당 부분이 이미 사용 중입니다. 컨테이너 2개 구성이 다운타임을 줄여주기 때문에, 현재 서버 실행이 여전히 진행 중이고 누출로 인해 메모리 사용량이 많이 증가했을 가능성이 있습니다.
업데이트 전에 재시작을 해보는 것이 도움이 될 수 있습니다. 재시작 전후의 스와프 사용량을 측정해 보세요.
내 서버 중 하나에 메모리 누수/확장 문제가 있는 것 같습니다. @RGJ님의 합리적인 제안에 따라, 월요일 아침(서유럽 시간)에 7일마다 재부팅되도록 크론 작업을 예약했습니다.
(문제가 있는 플러그인을 알고 있다고 생각하지만, 왜 메모리 누수/확장이 발생하는지 파악할 시간을 투자하지는 않았습니다)
이것은 OOM 킬로 보입니다. 현재 RAM이 약 2 GiB인데, 컨테이너 두 개를 재빌드할 때 기존 앱과 새 빌드가 겹치면서 메모리가 한계를 초과합니다. 부트스트랩 전에 스왑이 이미 약 3 GiB 사용된 상태라, 엠타일 빌드 시 메모리 사용량이 급증하면서 SIGKILL이 발생합니다. 실행 중인 컨테이너를 중지하거나(또는 컨테이너 하나만 재빌드하면) 겹침을 피할 수 있어 성공합니다. 다음 단계는 dmesg를 통해 이를 확인한 후, 재빌드 전에 재시작하거나 / 시간이 지남에 따라 스왑 사용량이 증가하는 원인을 조사하거나 / RAM을 추가하는 것입니다(이미 스왑이 많이 사용된 상태에서는 스왑만으로는 해결되지 않는 것 같습니다).
이 문제는 pnpm이나 Ember의 문제라기보다는 호스트가 단순히 메모리를 다 쓴 것으로 보입니다.
핵심은 SIGKILL입니다. 이는 보통 OS가 개입하여 프로세스를 종료한 것(대부분 OOM killer에 의해)을 의미하며, ember build -prod가 자체적으로 실패한 것은 아닙니다.
작은 규모의 호스트에서는 Ember 프로덕션 빌드가 RAM 수 GB까지 급격히 증가할 수 있습니다. 스왑이 활성화되어 있더라도, 스왑이 거의 사용된 상태에서는 커널이 메모리를 많이 사용하는 node 프로세스를 종료하도록 결정할 수 있습니다.
이 방향을 가리키는 몇 가지 징후:
따라서 스왑은 다소 도움이 되지만, 대부분 문제를 단순히 지연시킬 뿐입니다. 다른 컨테이너를 중지하면 메모리 압력이 충분히 낮아져 빌드가 완료됩니다.
도움이 되거나 도움이 될 수 있는 방법:
ember build -prod 실행 중에 다른 컨테이너를 중지합니다.NODE_OPTIONS=--max_old_space_size=1024) 피크 사용량을 줄입니다.이것이 왜 다소 무작위적으로 느껴지는지, 그리고 왜 다른 컨테이너를 중지하면 작동하는지 설명하는 데 도움이 되기를 바랍니다.
더 많은 스왑 공간이 도움이 될 것 같습니다. 해를 끼치지도 않을 것입니다. 총 스왑 용량을 보고 "많네"라고 생각하기보다는, 사용 가능한 스왑(free swap) 공간을 확인하여 재빌드(rebuild)에 충분한 여유 공간이 있는지 확인해 보세요.
또한 overcommit이 활성화되어 있는지 확인하세요.
좋은 아이디어네요! 서버 전체를 재부팅하시나요, 아니면 컨테이너만 재부팅하시나요?
이걸 "해결책"이라고 부르겠습니다. 깔끔하게 정리하기 위해서요. 
어쨌든, 다른 2GB+3GB 서버에서도 같은 문제가 발생했습니다. 그 후 web_only를 재부팅하고 다시 시도해 보니 정상적으로 작동했습니다. 메모리가 일정 수준 이하로 떨어지면 web_only를 재부팅하도록 도구에 추가할 것 같습니다.
비활성화하기 위해 아무것도 하지 않았습니다.
제가 직접 설정한 머신에서는 그렇게 합니다… 그리고 이 머신도 이미 켜져 있는 것으로 보입니다.
모두 아이디어를 주셔서 감사합니다!
서버 전체를 재부팅합니다 
제발, 이건 윈도우가 아니잖아. 
아이고, 그 시절이 생각나네! 
리눅스를 재부팅하는 것이 도움이 된 한 가지 사례는 확인했습니다. 보통 리눅스를 그렇게 보는 것을 좋아하지는 않지만, 여전히 단편화(fragmentation)가 발생할 수 있고, 메모리 누수가 발생할 가능성도 있습니다.