ember-cli 빌드 시 최소 인스턴스 크기에서 메모리 사용량으로 인한 OOM 실패 위험

지원 자체 호스팅
2

Hi @Ed_S - 이 테스트들을 진행할 때 어떤 버전의 Discourse를 사용하셨나요? 우리는 ember-cli와 그 애드온을 정기적으로 업데이트하고 있으므로, 동일한 환경에서 보고 있는지 확인하고 싶습니다.

또한, VM에 CPU 코어가 몇 개 있나요? 1개인가요? (콘솔에서 lscpu를 실행하여 확인할 수 있습니다)

모두 동일한 데이터로 작업할 수 있도록 다음을 실행해 보실 수 있을까요?

/var/discourse/launcher enter app
cd /var/www/discourse/app/assets/javascripts/discourse
apt-get update && apt-get install time
NODE_OPTIONS='--max-old-space-size=2048' /usr/bin/time -v yarn ember build -prod

제 테스트 드롭렛(1 CPU, 1GB RAM, 2GB 스왑)에서는 다음과 같은 결과가 나타났습니다:

Command being timed: "yarn ember build -prod"
	User time (seconds): 369.74
	System time (seconds): 22.62
	Percent of CPU this job got: 81%
	Elapsed (wall clock) time (h:mm:ss or m:ss): 8:02.73
	Average shared text size (kbytes): 0
	Average unshared data size (kbytes): 0
	Average stack size (kbytes): 0
	Average total size (kbytes): 0
	Maximum resident set size (kbytes): 774912
	Average resident set size (kbytes): 0
	Major (requiring I/O) page faults: 253770
	Minor (reclaiming a frame) page faults: 1158920
	Voluntary context switches: 519269
	Involuntary context switches: 383328
	Swaps: 0
	File system inputs: 7521784
	File system outputs: 316304
	Socket messages sent: 0
	Socket messages received: 0
	Signals delivered: 0
	Page size (bytes): 4096
	Exit status: 0

우리는 꽤 표준적인 ember 툴링을 사용하고 있으므로, 메모리 사용량을 줄이기 위해 설정 측면에서 우리가 할 수 있는 일이 많지 않을 것 같습니다. 장기적인 목표는 Embroider 사용을 도입하는 것이며, 이를 통해 더 많은 옵션을 얻을 수 있을 것입니다.