استخدام ذاكرة البناء في Ember-cli يخاطر بالفشل (OOM) على الحد الأدنى لحجم المثيل

مرحباً @Ed_S - ما هو إصدار Discourse الذي كنت تستخدمه لهذه الاختبارات؟ نقوم بتحديث ember-cli والإضافات الخاصة به بانتظام، لذا أريد فقط التأكد من أننا ننظر إلى نفس الشيء.

أيضًا، كم عدد نوى وحدة المعالجة المركزية التي تحتوي عليها أجهزتك الافتراضية؟ 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 وحدة معالجة مركزية، 1 جيجابايت من ذاكرة الوصول العشوائي، 2 جيجابايت من التبديل)، أرى هذا:

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، والذي قد يمنحنا المزيد من الخيارات.