Javascript heap out of memory как исправить

Недавно в компании Reside Real Estate столкнулись с проблемами: в самые ответственные моменты начал падать Node.js-сервер. Подозрение пало на память. Сотрудники компании прибегли к временным мерам, что позволило избавить от неудобств пользователей, и занялись поисками источника проблем. В результате им удалось найти и устранить неполадки.

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

Типы проблем с памятью

▍ Утечка памяти

В информатике утечка памяти — это разновидность неконтролируемого использования ресурсов, которая возникает, когда программа неправильно управляет выделением памяти, в результате чего память, которая больше не нужна, не освобождается.

В низкоуровневых языках вроде C утечки памяти часто возникают в ситуации, когда память выделяют, например так: buffer = malloc(num_items*sizeof(double));, но не освобождают после того, как память больше не нужна: free(buffer);.

В языках с автоматическим управлением освобождением памяти утечки возникают, когда к сущностям, которые больше не нужны, можно получить доступ из исполняющейся программы, или из некоего корневого объекта. В случае с JavaScript, любой объект, к которому можно обратиться из программы, не уничтожается сборщиком мусора, соответственно, место, которое он занимает в куче, не освобождается. Если размер кучи вырастет слишком сильно, возникнет ситуация нехватки памяти.

▍ Чрезмерное использование памяти

В ситуации чрезмерного использования памяти программа занимает гораздо больше памяти, чем ей нужно для решения возложенной на неё задачи. Например, такое может возникнуть тогда, когда ссылки на большие объекты хранят дольше, чем нужно для правильной работы программы, что предотвращает уничтожение этих объектов сборщиком мусора. Подобное случается и тогда, когда в памяти держат большие объекты, которые попросту не нужны программе (это вызывает одну из двух основных проблем, которые мы рассмотрим ниже).

Выявление проблем с памятью

Наши проблемы с памятью проявляли себя вполне очевидным образом, в основном — в виде этого мрачного сообщения из журнала:

FATAL ERROR: CALL_AND_RETRY_LAST Allocation failed - JavaScript heap out of memory

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

Признаки чрезмерного использования памяти обычно выражаются в низкой производительности программ. Однако, чрезмерное использование памяти без утечки со временем не приводит к падению производительности.

Временное решение проблемы

Часто, когда что-то случилось, нет времени на то, чтобы понять суть проблемы и всё исправить. У нас его точно не было. К счастью, есть способы увеличения объёма памяти, выделенной процессу Node. У движка V8 имеется стандартное ограничение памяти равное примерно 1.5 Гб на 64-битных компьютерах. Даже если вы запускаете процесс Node на компьютере, имеющем гораздо больше RAM, это роли не играет, если только вы не увеличите этот лимит. Для того, чтобы увеличить лимит, можно передать процессу Node ключ max_old_space_size. Выглядит это так:

node --max_old_space_size=$SIZE server.js

Параметр $SIZE задаётся в мегабайтах и, теоретически, может быть любым числом, которое имеет смысл на конкретном компьютере. В нашем случае был использован параметр 8000, который, с учётом особенностей работы сервера, позволил выиграть достаточно времени на исследования. Кроме того, мы увеличили динамическую память. Мы пользуемся Heroku, там это делается просто.

Также мы воспользовались сервисом Twilio, настроили его так, чтобы нас оповещали каждый раз, когда на сервер приходит запрос, требующий особенно много памяти. Это позволило нам наблюдать за запросом и перезапускать сервер после его завершения. Такое решение неидеально, но для того, чтобы наши пользователи не сталкивались с отказами, мы были готовы на всё, даже на круглосуточные дежурства без выходных.

Отладка

Итак, благодаря настройкам Node и организации мониторинга сервера мы выиграли время, которое можно было потратить на то, чтобы дойти до первопричины неполадки. На первый взгляд может показаться, что «проблема с памятью сервера» — это нечто ужасное, а для избавления от этой «проблемы» потребуются фантастические инструменты и умения. Однако, на самом деле, всё не так уж и страшно. Есть вполне доступные инструменты для исследования приложений, существует множество материалов, в которых можно найти подсказки. Мы, для исследования памяти Node-сервера, будем пользоваться инструментами разработчика Chrome.

▍ Снепшот кучи

«Утечка памяти» — это проблема, которая выражается в постоянно растущем размере кучи. В результате куча оказывается слишком большой для продолжения нормальной работы сервера. Поэтому в самом начале исследования нужно сделать несколько снепшотов (снимков состояния) кучи, с некоторым интервалом, и погрузиться в исследование этих снепшотов с использованием инструментов разработчика Chrome для того, чтобы понять, почему куча так велика и почему она растёт. Обратите внимание на то, что следует делать несколько снепшотов, через некоторое время, в результате можно будет изучить объекты, которые будут переходить из одного снепшота в другой. Эти объекты, вполне возможно, являются виновниками утечки памяти. Существует множество способов создать снепшот кучи.

▍ Использование heapdump для создания снепшотов кучи

Мы, для создания снимков кучи, пользовались heapdump. Этот npm-пакет оказался весьма полезным. Его можно импортировать в код и обращаться к нему в тех местах программы, где нужно делать снепшоты. Например, мы делали снепшот каждый раз, когда сервер получал запрос, который мог вызвать процесс, интенсивно использующий память. Тут же мы формировали имя файла, содержащее текущее время. Таким образом мы могли воспроизводить проблему, отправляя на сервер всё новые и новые запросы. Вот как это выглядит в коде:

import heapdump from 'heapdump';

export const handleUserRequest = (req) => {
  heapdump.writeSnapshot(
    `1.User_Request_Received-${Date.now()}.heapsnapshot`,
    (err, filename) => {
      console.log('dump written to', filename);
  });
  return startMemoryIntensiveProcess(req);
};

▍ Использование удалённого отладчика Chrome для создания снепшотов кучи

Если вы работаете с Node 6.3. или с более поздней его версией, для создания снепшотов кучи можно использовать удалённый отладчик Chrome. Для того, чтобы это сделать, сначала запустите Node командой такого вида: node --inspect server.js. Затем перейдите по адресу chrome://inspect. Теперь вы сможете удалённо отлаживать процессы Node. Чтобы сэкономить время, можете установить этот плагин Chrome, который автоматически откроет вкладку отладчика при запуске Node с флагом --inspect. После этого просто делайте снепшоты тогда, когда сочтёте это необходимым.

Средства удалённой отладки Chrome и создание снепшотов кучи

Загрузка снепшотов и определение типа проблемы с памятью

Следующий шаг заключается в загрузке снепшотов на закладке Memory (память) инструментов разработчика Chrome. Если вы использовали для создания снепшотов кучи удалённый отладчик Chrome, то они уже будут загружены. Если вы использовали heapdump, то вам понадобится загрузить их самостоятельно. Обязательно загружайте их в правильном порядке, а именно — в том, в котором они были сделаны.

Самое главное, на что надо обращать внимание на данном этапе работы, заключатся в том, чтобы понять — с чем именно вы столкнулись — с утечкой или с чрезмерным использованием памяти. Если перед вами утечка памяти, то вы, вероятно, уже получили достаточно данных для того, чтобы начать исследовать кучу в поисках источника проблемы. Однако, если перед вами — чрезмерное использование памяти, вам нужно попробовать некоторые другие методы анализа для того, чтобы получить содержательные данные.

Наша первая проблема с памятью выглядела, на закладке Memory инструментов разработчика Chrome, так, как показано ниже. Несложно заметить, что куча постоянно растёт. Это говорит об утечке памяти.

Куча увеличивается со временем — очевидная утечка памяти

Наша вторая проблема с памятью, которая возникла через пару месяцев после исправления утечки, в итоге, на тех же испытаниях, выглядела так, как показано на рисунке ниже.

Куча со временем не растёт — это не утечка памяти

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

Для выявления подобных проблем мы рекомендуем два способа, которые помогли нам обнаружить виновников проблемы — функцию и переменную. Это — запись профиля выделения памяти и создание снепшотов на сервере, находящемся под серьёзной нагрузкой.

Если вы используете версию Node 6.3 или более позднюю, вы можете записать профиль выделения памяти через удалённый отладчик Chrome, запустив Node с уже упоминавшимся ключом --inspect. Это даст сведения о том, как отдельные функции используют память с течением времени.

Запись профиля выделения памяти

Ещё один вариант заключается в отправке множества одновременных запросов к вашему серверу и в создании множества снепшотов во время обработки этих запросов (предполагается, что сервер работает асинхронно, как результат, некоторые снепшоты могут оказаться гораздо больше других, что укажет на проблему). Мы бомбардировали сервер запросами и делали снепшоты. Некоторые из них оказались очень большими. Исследованием этих снепшотов можно заняться для выявления источника проблемы.

Анализ снепшотов

Теперь у нас есть данные, которые вполне могут помочь найти виновников проблем с памятью. В частности, рассмотрим анализ ситуации, в которой размеры последовательно сделанных снепшотов растут. Вот один из снепшотов, который загружен на вкладке Memory инструментов разработчика Chrome.

Исследование утечки памяти — все функции указывают на наш сервис электронной почты

Показатель Retained Size — это размер памяти, освобождённой после того, как объект удалён вместе со своими зависимыми объектами, которые недостижимы из корневого объекта.

Анализ можно начать с сортировки списка по убыванию по параметру Retained Size, после чего приступить к исследованию больших объектов. В нашем случае имена функций указали нам на ту часть кода, которая вызывала проблему.

Так как мы были уверены в том, что перед нами утечка памяти, мы знали, что исследование стоит начать с поиска переменных с неподходящей областью видимости. Мы открыли файл index.js почтовой службы и тут же обнаружили переменную уровня модуля в верхней части файла.

const timers = {};

Мы со всем этим разобрались, внесли необходимые изменения, протестировали проект ещё несколько раз и исправили в итоге утечку памяти.

Вторую проблему отлаживать было сложнее, но тут сработал тот же подход. Ниже показан профиль выделения памяти, который мы записали с использованием инструментов разработчика Chrome и ключа Node --inspect.

Поиск виновников чрезмерного использования памяти

Так же как при анализе данных в ходе поиска утечки памяти, многие имена функций и объектов с первого взгляда узнать не удаётся, так как находятся они на более низком уровне, чем код, который пишут для Node.js. В подобной ситуации следует, встретив незнакомое имя, записать его.

Профиль выделения памяти привёл нас к одной из функций, recordFromSnapshot, она стала хорошей отправной точкой. Наше исследование снепшота кучи, которое не особенно отличалось от исследования, выполняемого при поиске утечки памяти, позволило обнаружить очень большой объект target. Это была переменная, объявленная внутри функции recordFromSnapshot. Эта переменная осталась от старой версии приложения, она была больше не нужна. Избавившись от неё, мы исправили ситуацию с чрезмерным использованием памяти и ускорили выполнение процесса, которое раньше занимало 40 секунд, до примерно 10 секунд. При этом процессу не требовалась дополнительная память.

Итоги

Две вышеописанные проблемы с памятью заставили нас притормозить развитие нашего проекта, которое до этого шло очень быстро, и проанализировать производительность сервера. Теперь мы понимаем особенности производительности сервера на гораздо более глубоком уровне, чем раньше, и мы знаем, сколько времени нужно для нормального выполнения отдельных функций, и сколько памяти они используют. У нас появилось гораздо лучшее понимание того, какие ресурсы нам нужны при дальнейшем масштабировании проекта. И, что самое важное, мы перестали бояться проблем с памятью и перестали ожидать их появления в будущем.

Уважаемые читатели! Сталкивались ли вы с проблемами, связанными с памятью в Node.js? Если да — просим рассказать о том, как вы их решали.

Sign Up for Our Newsletters

Subscribe to get notified of the latest articles. We will never spam you. Be a part of our ever-growing community.

By checking this box, you confirm that you have read and are agreeing to our terms of use regarding the storage of the data submitted through this form.

JavaScript heap out of memory is a common issue that occurs when there are a lot of processes happening concurrently. The default JavaScript heap size allocated by Node.js requires additional space to smoothly run its operations; thus, creating a JavaScript issue.

In this article, we will be discussing JavaScript memory and how to clear some space, so let’s dive right into it.

JavaScript Out of Memory: Solving the Issue

To solve JavaScript heap size, we must maximize space before running the script. In other computer languages, there are manual management options such as free() and malloc(). However, JavaScript heap size allocates memory during the creation of objects. This JavaScript free memory is available once objects are sent to garbage, or when not in use.

To understand the JavaScript memory issue better, let’s see an example of a JavaScript heap size warning. Refer to the following error:

FATAL ERROR: Ineffective mark-compacts near heap limit Allocation failed – JavaScript heap out of memory

FATAL ERROR: CALL_AND_RETRY_LAST Allocation failed – JavaScript heap out of memory

– Explaining the Memory Heap Issue

The example shown above is a common sight when working with large projects. The default JavaScript heap size allocated by node gets overburdened and commands are not effectively completed.

This can also occur if there are a lot of modules to npm install from the package.json file.

Fixing JavaScript Memory

The easiest way to JavaScript free memory is by increasing the memory allocated to a command and running it before starting with the project. Below, we can see the effect on macOS and Windows operations. Do note that Linux users can tally macOS as their go-to method.

– In Windows

To increase the allocation of JavaScript memory in Windows, follow these steps:

1. Go to control panel
2. Head over to System
3. In the system menu, click on Advanced System Settings
4. You should see an option named variables, so please go ahead and click that option
5. Now, click on new user or new system
6. Once you add the variable name and value, clicking on “ok” will get the job done.

Alternatively, we can also use powershell, which we will explain below.

Powershell Method

Through the Powershell method, we can increase the memory if needed. For larger projects, we can add a ceiling of as much as 12-14 GB, considering the project is large enough. The following example shows a code application through powershell:

$env:NODE_OPTIONS=”–max-old-space-size=Desiredvalue”

– MacOS

Do note that even the latest node versions have a memory limit below two gigabytes (GB). In the example below, we used the –max-old-space-size option, as you can see:

sampleproject test
export NODE_OPTIONS=–max-old-space-size=Desiredvalue
sampleproject monitor

Let’s see some more examples for a better understanding.

– More Examples Increasing Memory in MacOs

Node versions default storage of two GB can be increased, so let’s go ahead and try to increase the limit around four GB in the example below:

node –max-old-space-size=4096 index.js

Increasing Memory During NPM Install

In some cases, we might want to add this node to the NPM install. Here is how you can do it if you prefer so:

node –max-old-space-size=4096 `which npm` install

– Increasing Memory In Ranges

Sometimes, a project needs more than a four GB JavaScript memory. To increase it even further, we can use a greater JavaScript heap size, starting from a single GB and continuing to four GB. You can see how we’ve done that in the following example:

From the example shown above, we started from one GB and continued until we increased the memory to four GB.

Pros and Cons of Node.js in JavaScript: Allocating the Heap Size

As Node.js is an important concept, let’s briefly discuss its benefits and drawbacks.

– Benefits of Node.js in JavaScript

Some of the benefits of Node.js are as follows:

• Scaling of applications is done in horizontal and vertical direction.
• We can add extra resources to the nodes, an option not provided by other JavaScript servers.
• Node.js is easy-to-use at the backend and conserves time.
• It helps write server-side applications; thus, both frontend and backend applications work in a runtime environment.
• Node.js serves both the client and the server-side applications since it is a full-stack development model.
• JavaScript code is interpreted by Node.js through Google’s V8 JavaScript engine, making it faster in its operations.

– Drawbacks of Node.js in JavaScript

Moreover, here are some of the drawbacks of Node.js:

• The Application Programming Interface (API) keeps changing at frequent intervals, compromising on stability.
• Compared to the other languages, the library system of JavaScript is not well-equipped. So, developers cannot implement easy tasks using Node.js.
• Since Node.js is asynchronous, the code is not stable and developers have to use nested calls.

In contrast to the pros and cons, Node.js has helped JavaScript by providing it with a backend for complex queries and processing options. Even though JavaScript does not have a resourceful library, using NPM to download libraries and modules is also an added option.

Example Using an Array

The following example is using array and JavaScript memory to fix the heap:

const array = [];
while (true) {
array.push(new Array(10000000));
const memory = process.memoryUsage();
console.log((memory.heapUsed / 1024 / 1024 / 1024).toFixed(4), ‘GB’);
}

Ways to Prevent This Issue

In most cases, increasing the JavaScript memory should do the trick. However, there are times when the system is maxed out and the increasing option is not sufficient. In such a scenario, we can use the following ways to prevent the problem.

– Split Data In Small Groups

Most larger projects are compilations of data, making them huge entries for the system to process. This can be done through MongoDB databases and other types. Furthermore, this procedure is applicable for all the Extract, transform and load (ETL) operations.

Simply put, we will split a file in the number of lines and the number of users.

– Preventing Memory Leakage

If an application keeps showing a JavaScript memory issue, chances are there may be leaks within the memory of that application. If that’s the case, increasing the memory would just be a temporary fix. So, to prevent such mishaps, follow these guidelines:

• We must trace the intervals, timers, variables, and any references that are no longer needed.
• Profiling can help detect such leaks. For frontend, we can profile JavaScript memory by visiting the Memory lab.
• Using Node.js, we can work with Chrome to debug memory usage by running the application in inspection mode. For example, we can use node –inspect index.js.
• We can identify the processes and perform a restart. This is great for machines with limited memory options.

Freeing Memory

We must remember memory cycle is similar for all the programming languages, and it involves these three steps:

1. Allocation of the memory
2. Using the allocated memory
3. Releasing the allocated memory if no longer required

Lastly, let’s discuss the allocation of the JavaScript memory.

– Allocation of the Memory

When the values are declared, JavaScript automatically allocates memory. Here is a way to do it with the following example:

var n = 123;
var s = ‘abc’; //
var o = {
a: 1,
b: null
};
var a = [1, null, ‘abcd’];
function f(a) {
return a + 2;
}
someElement.addEventListener(‘click’, function() {
someElement.style.backgroundColor = ‘blue’;
}, false);

In the example above, we have used numbers, strings, arrays, objects, and functions.

– Using the Memory

Let’s say that we allocated the memory in the example shown above. Once allocated, we can use the value of a variable, object for reading and writing. We can also pass an argument to work accordingly with the function.

– Releasing Memory

When we are ready to release the memory, proper management is a must to avoid a JavaScript issue. Do note this is a crucial step in memory management because finding out the optimum time of release is difficult.

Garbage Collection in JavaScript

For the lower languages, developers have to determine the releasing time. However, for JavaScript (higher language), we use something called “garbage collection”.

Garbage collection uses automatic memory management as mentioned earlier. In simple words, when memory is no longer needed, the system provides an estimated time for release that is not always right as memory might still be in use.

– References in JavaScript Memory Management

By using a garbage collecting model, we can reduce the approximate JavaScript issue of releasing the memory by counting the references. If zero references are pointing towards an object, it is considered garbage and is released.

Moreover, you will find a simple garbage collection method in the example below:

var x = {
a: {
b: 2
}
};
var y = x;
x = 1;
var z = y.a;
y = ‘browser’;
z = null;

In the example shown above, we have references in different numbers pointing at the objects. While some instances have references pointing at each other, the z=null has zero references. Thus, it can be garbage-collected.

Final Thoughts

In the article, we discussed the basics of the JavaScript issue of memory and the methods to free some space, either by increasing or through other procedures. Let’s quickly glance at the summarizing points from this guide:

• The usage of Node.js helps JavaScript provide the backend functionality
• Normally, an increase in memory should be fine unless there is a memory leak
• If there is a memory leak, we have provided a direct guide on how to deal with it above
• To prevent inaccurate estimation by garbage collection method, references are counted to release memory at the right time.

By now, you should have an ample understanding of JavaScript heap size. Still, don’t worry if you don’t get it yet, as you can come back here and use the practice coding examples any time.