Я заметил, что нашему приложению узла не хватает памяти примерно через день. Память потребляется заданием, которое выполняется каждую минуту или около того, потому что это почти единственное, что происходит сейчас. Когда я запускаю приложение локально на своей машине, я вижу, что приложение также достигает потолка памяти, а затем включается сборка мусора.
На heroku кажется, что он выходит за пределы потолка памяти нашего экземпляра 1G RAM, и GC не срабатывает. Интересно, связано ли это с тем, что узел настроен с более высоким пределом памяти, чем настоящий Dyno.
Перефразируйте: привязан ли предел памяти node.js к herkou к пределу памяти Dyno?
Вот ответ от heroku. Похоже, вам нужно внести изменения в конфигурацию, и вы не можете использовать готовую конфигурацию.
Привет, Стэн,
Спасибо за ссылку на эти документы; Мне нужно обновить этот пример терминала, поскольку я недавно отключил болтливый вывод WEB_CONCURRENCY. Мы добавили ведение журнала, когда добавили эту функцию, в основном, чтобы люди не были удивлены появлением этих новых переменных, вторгающихся в их среду.
Чтобы увидеть значения для вашего приложения, вы можете запустить:
$ heroku run 'echo $ WEB_MEMORY, $ WEB_CONCURRENCY' Однако позвольте мне пояснить - эти значения существуют только для определения того, сколько параллельных процессов должно запускаться приложением кластеризованного узла, и даже тогда, только если вы решите использовать значение WEB_CONCURRENCY в ваш код. Они вообще не влияют на двоичный файл узла или его распределение памяти по умолчанию или сборку мусора, которые являются полностью стандартными, ванильными версиями, загруженными с nodejs.org/dist:
https://devcenter.heroku.com/articles/node-concurrency#tuning-the-concurrency-level V8 использует жадный и ленивый подход к сборке мусора. Кроме того, V8 по умолчанию предполагает, что у вас есть около 1,5 ГБ для работы (больше, чем ограничение в 1 ГБ для 2X dyno). У вас есть несколько вариантов, если вы заинтересованы в изменении поведения памяти узла по умолчанию:
Вручную запускайте сборщик мусора всякий раз, когда объем памяти превышает установленный предел (https://simonmcmanus.wordpress.com/2013/01/03/forcing-garbage-collection-with-node-js-and-v8/)
Установите max_old_space_size ниже значения по умолчанию (например, node --max_old_space_size = 960). Некоторые метрики в исходном коде v8 привязаны к max_old_space_size, так что это может сделать gc несколько более агрессивным. Обратной стороной является то, что если вы превысите значение даже на байт, ваша программа выйдет из строя.
Задайте для gc_global значение true, чтобы принудительно выполнять всегда глобальный сбор (по умолчанию false - имейте в виду, что глобальный сбор выполняется медленнее, чем многофазный сбор по умолчанию).
Установите для nolazy_sweeping значение true, что также сделает gc более агрессивным.
Имейте в виду, что если вы превышаете примерно 1 ГБ памяти в процессе с одним узлом, лучше всего разделить этот процесс на несколько рабочих:
https://github.com/joyent/node/wiki/FAQ#what-is-the-memory-limit-on-a-node-process Ура, Охотник