Практическое руководство по борьбе с утечками памяти в Node.js

[AlexSpaizNet]

При создании дампа кучи принудительно запускается сборщик мусора. В результате нам не нужно беспокоиться о тех объектах, которые могут быть удалены сборщиком мусора в будущем, но пока находятся в куче. То есть — об объектах, при работе с которыми утечек памяти не происходит.

Не очень понимаю… Как мне в дампе отличить объекты которые не будут удалены никогда от объектов «которые могут быть удалены сборщиком мусора в будущем»? Ведь если я запустил дамп когда у меня сотни или тысячи реквестов которые еще не закончили свою работу, в дампе будет много данных. Как понять где утечка среди всего этого?

Вот у нас бежит сервис в проде. Сервис писался лет 5. Там все: экспресс, раббит, любимый ивент емиттер. На нью-релике видим память бежит. Но бежит ооооочень медленно. Обычно до out of memory не доходит потому что деплоим часто.

Так вот когда открываешь дамп этого чуда, там столько всего… Сервис живой получает огромное количество запросов, отправляет месседжы и т.д. Пока что вот так в лоб скачиванием дампа найти утечку не удалось :/

Вообще в голове крутится сделать вот так:
1. Запустить сервак
2. Сделать дамп
3. Поставить сервак под лоад-балансер и дать недельку поработать
4. Вывести сервак из-под лоад-балансера. Удостовериться все реквесты и отложенные функции закончили работать.
5. Сделать дамп
6. Сравнить и надеяться на удачу

Может еще какие техники посоветуете? Ну или если я ошибаюсь, ткните носом :)

[mSnus]

Интересно, а статические анализаторы типа Радужного Единорога Студио такие вещи не отлавливают?

[DimoNj]

Очень классный материал, спасибо! Нужно взять на вооружение этот прием.

[DmitryKoterov]

Кстати, на удивление стабильно работает флаг node --inspect: в этом случае node начинает слушать на указанном порту, и если этот порт отфорвардить на localhost и просто в хроме открыть chrome://inspect, то он его прямо там увидит (у него есть пара «портов по умолчанию», похоже) и предложит подключиться. Ну и уж там в UI есть и дамп памяти, и сравнение, и профилирование cpu, и даже пошаговый отладчик.

[polRk]

В данном примере не утечка памяти. Вы выбрали очень плохой пример! Просто очень очень плохой пример. Ибо если переменная используется вне контекста запроса, на то есть причины. К примеру, нужно считать кол-во запросов на route. Такую переменную нельзя хранить в контексте запроса, только вынести ее за пределы запроса. Статья и неправильный пример, ради того, чтоб показать, как работает inspect? RUVDS чем больше пишете, тем хуже получается.