Сборка Ember CLI убита

Я создаю свое приложение Ember CLI внутри док-контейнера при запуске. Сборка завершается с ошибкой без сообщения об ошибке, она просто говорит 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

Тот же образ Docker успешно запускается в другой среде, но без аппаратных ограничений. Есть ли в Ember CLI жестко запрограммированные аппаратные ограничения для процесса сборки? Оперативная память ограничена 128 м и подкачивается до 2 г.


docker docker-compose ember.js ember-cli
person alsdkjasdlkja    schedule 23.01.2016    source источник

Ответы (1)


arrow_upward
2
arrow_downward

Скорее всего, Ember CLI недостаточно памяти, чтобы делать то, что ему нужно. Вы правы в том, что процесс убивается из-за ситуации с OOM. Если вы войдете на хост и посмотрите на вывод dmesg, вы, вероятно, увидите что-то вроде:

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

Возможно, стоит профилировать контейнер, используя что-то вроде https://github.com/google/cadvisor, чтобы выяснить, какие максимумы памяти ему могут понадобиться.

person Andy Shinn    schedule 23.01.2016
comment
Ты прав. Я перешел на лимит памяти 512м и теперь работает :) - person alsdkjasdlkja; 24.01.2016