Node.js "FATAL ERROR: JS Allocation failed - процесс из памяти" - можно получить трассировку стека?

Хорошо... Я вернусь на круги своя. Я не могу понять это для жизни меня.

Я получаю следующую ошибку:

FATAL ERROR: JS Allocation failed - process out of memory

Я мог бы перечислять десятки (да, десятки) вещей, которые я пытался найти в корне этой проблемы, но на самом деле это было бы слишком много. Итак, вот ключевые моменты:

  • Я могу получить его только на моем рабочем сервере, и мое приложение является большим и сложным, поэтому очень сложно изолировать
  • Это случается, несмотря на то, что размер кучи и размер RSS являются как < 200 Мбайт, что не должно быть проблемой, учитывая, что машины (Amazon Cloud, CentOS, m1.large) имеют ОЗУ 8 ГБ.

Мое предположение состоит в том, что (из-за второй точки) утечка, вероятно, не является причиной; скорее, похоже, что объект SINGLE очень большой. Следующий поток поддерживает эту теорию:: В Node.js, используя JSON.stringify, приводит к ошибке "process out of memory"

Что мне действительно нужно, так это узнать, какое состояние памяти находится в момент сбоя приложения, или, может быть, трассировка стека, ведущая к FATAL ERROR.

Основываясь на моем предположении выше, 10-минутный куча кучи недостаточен (так как объект не будет находиться в памяти).

Ответы

Ответ 1

Мне нужно дать огромный реквизит Тревор Норрис на этом, помогая изменить node.js, чтобы он автоматически генерировал куча дампа при возникновении этой ошибки.

В конечном итоге решение этой проблемы для меня было гораздо более мирским. Я написал несколько простых кодов, которые добавили конечную точку каждого входящего запроса API в файл журнала. Я ждал, чтобы собрать ~ 10 точек данных (сбоев) и сравнил конечные точки, которые были запущены за 60 секунд до крушения. Я обнаружил, что в 9/10 случаях единственная конечная точка, которая была поражена непосредственно перед сбоем.

Оттуда это был просто вопрос углубления в код. Я все сократил - возвращая меньше данных из моих запросов mongoDB, передавая только необходимые данные от объекта обратно к обратному вызову и т.д. Теперь мы перешли на 6 раз больше, чем в среднем, без единого сбоя на любом из серверов, что привело меня к надеюсь, что он разрешен... пока.

Ответ 2

Просто потому, что это самый верный ответ в Google на данный момент, я решил, что добавлю решение для случая, с которым я только что столкнулся:

У меня была эта проблема с использованием экспресс с шаблонами ejs - проблема в том, что я не смог закрыть блок ejs, а файл был js-кодом - примерно так:

var url = '<%=getUrl("/some/url")'
/* lots more javascript that ejs tries to parse in memory apparently */

Это, очевидно, супер конкретный случай, решение OP должно использоваться в большинстве случаев. Однако решение OP не будет работать для этого (трассировка стека ejs не будет отображаться с помощью ofe).

Ответ 3

Нет единственного решения этой проблемы.
Я читал разные случаи, большинство из которых были связаны с JS, но в моем случае, например, это был просто разбитый цикл шаблона нефрита, который был бесконечным из-за ошибки кода.

Я предполагаю, что это просто синтаксическая ошибка, с которой node плохо справляется.
Проверьте свой код или разместите его, чтобы найти проблему.

Ответ 4

В моем случае я развертывал Rails 4.2.1 через развертывание кепки (capistrano) и во время полученных прекомпиляций:

rake stdout: rake aborted! ExecJS:: RuntimeError: FATAL ERROR: сбой эвакуации - обработка из памяти (Execjs): 1

Я запустил дюжину импорта данных с помощью active_admin раньше, и, похоже, он использовал всю RAM

Решение: Перезагрузка сервера и развертывание выполняются в первый раз....

Ответ 5

Может быть проблема с рекурсией на объекте, который вы сериализуете, просто для начала, и заканчивается память, прежде чем рекурсия станет проблемой?

Я создал safe-clone-deep npm модуль по этой причине... в основном вы захотите сделать следующее.

var clone = require('safe-clone-deep');
...
   return JSON.stringify(clone(originalObject));

Это позволит вам клонировать почти любой объект, который затем будет сериализоваться безопасно. Кроме того, если один из объектов наследует от Error, он будет сериализовать унаследованные свойства name, message и stack, поскольку они обычно не сериализуются.

Ответ 7

В моем случае я инициализировал ассоциативный массив (Object), используя []. Как только я инициализировал это как {}, проблема исчезла.

Ответ 8

В моем случае файл, который я использовал, чтобы засеять db во время разработки, вызывал утечку. По какой-то причине node не понравился многострочный комментарий, который у меня был в конце файла. Я не вижу в этом ничего плохого, но процесс исключения означает, что я знаю этот раздел этого файла.

Ответ 9

Анализируя ряд случаев, наиболее распространенной проблемой является проблема бесконечного цикла. Это сложно будет решить в сложном приложении, то есть там, где разработка, основанная на тестах, пригодится!

Ответ 10

Я потратил несколько дней, чтобы найти причину проблемы. Ошибка "JS - process out of memory" начала возникать при сборке веб-пакета только в экземпляре AWS EC2. Сборка прошла успешно в моей локальной системе.
Причиной был следующий код:
Предыдущая:
import { ShoppingCartOutlined } from "@material-ui/icons/ShoppingCartOutlined";
Это было исправлено:
import ShoppingCartOutlined from "@material-ui/icons/ShoppingCartOutlined";

Это может помочь кому-то, использующему material-ui/icons, и закончится с этой ошибкой.

Ответ 11

Обмен тем, что происходит здесь:

Я потерял несколько дней с этой проблемой, пока не обнаружил, что в каком-то файле я импортировал класс из одного статического файла, построенный файл. Это заставляет процесс сборки никогда не заканчиваться. Что-то вроде:

import PropTypes from "../static/build/prop-types";

Исправление к реальному источнику решило всю проблему.

Ответ 12

Используя npm 5.0.3 на экземпляре AWS, у нас были проблемы с разрешениями в самой глобальной папке npm, что, вероятно, вызвало это с нами. мы побежали: sudo chown -R $(whoami) $(npm config get prefix)/{lib/node_modules,bin,share} теперь он отлично работает

Ответ 13

У меня такая же проблема. Я перезапустил систему с помощью команды "sudo reboot". Затем попробовал еще раз. Это сработало.