(здесь разработчик V8.)
Код, сгенерированный V8, находится в куче, поэтому, если куча не растет, это означает, что код тоже не растет.
Размер стека ограничен операционной системой, обычно 1-8 МБ. Поскольку операционные системы просто убивают процессы, которые достигают предела стека, V8 накладывает на себя еще более низкий предел (чуть меньше мегабайта, я думаю, что сейчас он составляет 984 КБ) и выдает RangeError, если он когда-либо будет превышен. Таким образом, растущий стек также не может быть вашей проблемой.
Поскольку вы говорите, что объем динамической памяти, о которой сообщает Node / V8, остается постоянным, это также означает, что большинство руководств по «отладке утечек памяти в Node» не требуется. применимо к вашей ситуации; и это, вероятно, также означает, что утечка не в вашем (JavaScript) коде.
Это оставляет C ++ «память кучи» (которая сильно отличается от управляемой «кучи» V8!) как наиболее вероятный виновник , Сам узел, а также собственные расширения могут свободно распределять память, которой они управляют сами. Возможно, что-то там не убирается должным образом. Это может быть просто ошибка вверх по течению; или это может быть из-за того, что что-то в вашем коде случайно удерживает некоторую память для встраивания.
Сначала я попытался бы обновить Node и все установленные вами собственные расширения. Возможно, утечка уже найдена и устранена.
Если это не поможет, то вы можете попытаться выяснить, куда уходит память. Например, вы можете скомпилировать все из исходного кода с включенным LSan и посмотреть, сообщает ли это что-нибудь. Вероятно, было бы полезно создать стресс-тест, например, фальшивый клиент, который заполняет (тестовый экземпляр) ваш сервер реальными запросами, чтобы попытаться вызвать проверяемые случаи утечки в секундах или минутах, а не месяцах. Создание такого поддельного клиента может также помочь сузить, где вещи go неправильны (например: возможно, вы заметите, что один тип запроса не вызывает утечку, а другой тип запроса делает).