Всплыл тут вопрос — сколько памяти потребляет node.js. То есть конфигурируете вы VDS и всплывает вопрос, какой объём памяти нужно поставить в виртуалку.
Достаточно очевидно, что всё зависит от вашего приложения и нужно измерять его, но всё же есть у node.js такая особенность, что размер кучи в V8 задан конфигурацией и если вы вылезете за него, то случится OOM (heap out of memory). Потому все ребята с жирными бандлами (а в моём опыте больше всего потребляла всегда именно параллельная сборка тяжёлых проектов, а не рантайм) знают про ключик --max-old-space-size через который можно подкинуть памяти в кучу или ограничить её, чтобы словить OOM пораньше и устранить утечку. Молодое же пространство маленькое и особо ни на что не влияет, потому крутим именно old_space.
Однако есть интересный вопрос — а какой же размер кучи по умолчанию? Достаточно долго (до node.js 12) мы жили в парадигме, что у нас есть 1.34Gb кучи для 64-битных платформ. А дальше стало интересней. Во-первых нода научилась читать лимиты в cgroups. Теперь запуская ноду в контейнере вы автоматически получается соответствие размера кучи и лимита памяти контейнера. Во-вторых дефолтные лимиты изменились. Так как документации на дефолты нет, то сообщество просто померило их руками, забивая память в цикле и ожидая ошибки. Вышло вот так (для 64 бит):
Node.js Version Limit
----------------- -------
18.x 4.0 GB
17.x 4.0 GB
16.x 4.0 GB
15.x 4.0 GB
14.x 4.0 GB
13.x 2.0 GB
12.x 2.0 GB
11.x 1.4 GB
10.x 1.4 GB
9.x 1.4 GB
Вообще сколько я мерил рантайм на проектах — редко добивало даже до гигабайта, если не случалось утечки (а с утечкой нет смысла докручивать память, вы всё равно рухнете, позже, но рухнете). Как уже написал выше, гораздо критичнее память на сборке, тестах и прочем «параллельном» CI. Вот там нужно правильно подобрать и сервер и лимиты в самой ноде. В обычном же рантайме не забываем следить за метриками, потребление памяти должно быть пилообразным и относительно небольшим (хотя кто знает, что у вас там за рантайм, может вы числодробилку с мемоизацией запускаете).
Достаточно очевидно, что всё зависит от вашего приложения и нужно измерять его, но всё же есть у node.js такая особенность, что размер кучи в V8 задан конфигурацией и если вы вылезете за него, то случится OOM (heap out of memory). Потому все ребята с жирными бандлами (а в моём опыте больше всего потребляла всегда именно параллельная сборка тяжёлых проектов, а не рантайм) знают про ключик --max-old-space-size через который можно подкинуть памяти в кучу или ограничить её, чтобы словить OOM пораньше и устранить утечку. Молодое же пространство маленькое и особо ни на что не влияет, потому крутим именно old_space.
Однако есть интересный вопрос — а какой же размер кучи по умолчанию? Достаточно долго (до node.js 12) мы жили в парадигме, что у нас есть 1.34Gb кучи для 64-битных платформ. А дальше стало интересней. Во-первых нода научилась читать лимиты в cgroups. Теперь запуская ноду в контейнере вы автоматически получается соответствие размера кучи и лимита памяти контейнера. Во-вторых дефолтные лимиты изменились. Так как документации на дефолты нет, то сообщество просто померило их руками, забивая память в цикле и ожидая ошибки. Вышло вот так (для 64 бит):
Node.js Version Limit
----------------- -------
18.x 4.0 GB
17.x 4.0 GB
16.x 4.0 GB
15.x 4.0 GB
14.x 4.0 GB
13.x 2.0 GB
12.x 2.0 GB
11.x 1.4 GB
10.x 1.4 GB
9.x 1.4 GB
Вообще сколько я мерил рантайм на проектах — редко добивало даже до гигабайта, если не случалось утечки (а с утечкой нет смысла докручивать память, вы всё равно рухнете, позже, но рухнете). Как уже написал выше, гораздо критичнее память на сборке, тестах и прочем «параллельном» CI. Вот там нужно правильно подобрать и сервер и лимиты в самой ноде. В обычном же рантайме не забываем следить за метриками, потребление памяти должно быть пилообразным и относительно небольшим (хотя кто знает, что у вас там за рантайм, может вы числодробилку с мемоизацией запускаете).