灰烬CLI构建被杀死

Question

I build my Ember CLI app inside a docker container on startup. The build fails without an error message, it just says killed :

root@fstaging:/frontend/source# node_modules/ember-cli/bin/ember build -prod                   
version: 1.13.15
Could not find watchman, falling back to NodeWatcher for file system events.
Visit http://www.ember-cli.com/user-guide/#watchman for more info.
Buildingember-auto-register-helpers is not required for Ember 2.0.0 and later please remove from your `package.json`.
Building.DEPRECATION: The `bind-attr` helper ('app/templates/components/file-selector.hbs' @ L1:C7) is deprecated in favor of HTMLBars-style bound attributes.
        at isBindAttrModifier (/app/source/bower_components/ember/ember-template-compiler.js:11751:34)
Killed

The same docker image successfully starts up in another environment, but without hardware constraints. Does Ember CLI have hard-coded hardware constraints for the build process? The RAM is limited to 128m and swap to 2g.

Answer 1

That is likely not enough memory for Ember CLI to do what it needs. You are correct in that, the process is being killed because of an OOM situation. If you log in to the host and take a look at the dmesg output you will probably see something like:

V8 WorkerThread invoked oom-killer: gfp_mask=0xd0, order=0, oom_score_adj=0
V8 WorkerThread cpuset=867781e35d8a0a231ef60a272ae5d418796c45e92b5aa0233df317ce659b0032 mems_allowed=0
CPU: 0 PID: 2027 Comm: V8 WorkerThread Tainted: G           O    4.1.13-boot2docker #1
Hardware name: innotek GmbH VirtualBox/VirtualBox, BIOS VirtualBox 12/01/2006
 0000000000000000 00000000000000d0 ffffffff8154e053 ffff880039381000
 ffffffff8154d3f7 ffff8800395db528 ffff8800392b4528 ffff88003e214580
 ffff8800392b4000 ffff88003e217080 ffffffff81087faf ffff88003e217080
Call Trace:
 [<ffffffff8154e053>] ? dump_stack+0x40/0x50
 [<ffffffff8154d3f7>] ? dump_header.isra.10+0x8c/0x1f4
 [<ffffffff81087faf>] ? finish_task_switch+0x4c/0xda
 [<ffffffff810f46b1>] ? oom_kill_process+0x99/0x31c
 [<ffffffff811340e6>] ? task_in_mem_cgroup+0x5d/0x6a
 [<ffffffff81132ac5>] ? mem_cgroup_iter+0x1c/0x1b2
 [<ffffffff81134984>] ? mem_cgroup_oom_synchronize+0x441/0x45a
 [<ffffffff8113402f>] ? mem_cgroup_is_descendant+0x1d/0x1d
 [<ffffffff810f4d77>] ? pagefault_out_of_memory+0x17/0x91
 [<ffffffff815565d8>] ? page_fault+0x28/0x30
Task in /docker/867781e35d8a0a231ef60a272ae5d418796c45e92b5aa0233df317ce659b0032 killed as a result of limit of /docker/867781e35d8a0a231ef60a272ae5d418796c45e92b5aa0233df317ce659b0032
memory: usage 131072kB, limit 131072kB, failcnt 2284203
memory+swap: usage 262032kB, limit 262144kB, failcnt 970540
kmem: usage 0kB, limit 9007199254740988kB, failcnt 0
Memory cgroup stats for /docker/867781e35d8a0a231ef60a272ae5d418796c45e92b5aa0233df317ce659b0032: cache:340KB rss:130732KB rss_huge:10240KB mapped_file:8KB writeback:0KB swap:130960KB inactive_anon:72912KB active_anon:57880KB inactive_file:112KB active_file:40KB unevictable:0KB
[ pid ]   uid  tgid total_vm      rss nr_ptes nr_pmds swapents oom_score_adj name
[ 1993]     0  1993      380        1       6       3       17             0 sh
[ 2025]     0  2025   203490    32546     221     140    32713             0 npm
Memory cgroup out of memory: Kill process 2025 (npm) score 1001 or sacrifice child
Killed process 2025 (npm) total-vm:813960kB, anon-rss:130184kB, file-rss:0kB

It might be worthwhile to profile the container using something like https://github.com/google/cadvisor to find out what kind of memory maximums it may need.