Vite, OOM и сервер на 4 ГБ: как мы снизили память сборки на 52%

[AnnSerba]

Про защиту сервера: даже если пик сборки уменьшить, остаётся вопрос, кого убьёт OOM killer в следующий раз. У нас в похожей ситуации помог не лимит Node, а cgroup на всю сборку: systemd-run --scope -p MemoryMax=2G -p MemoryHigh=1.8G, тогда за границей памяти умирает сам билд, а не MySQL рядом. Плюс oom_score_adj для базы, чтобы при живом выборе ядро смотрело в сторону сборщика.

И ещё одна ручка, которую редко трогают, если хочется остаться на Vite: build.rollupOptions.maxParallelFileOps. По умолчанию Rollup читает файлы параллельно, и на большом графе это как раз тот случай, когда снижение параллелизма экономит память почти без потери времени на четырёх CPU.

[gilbertfrost]

Спасибо за совет! В целом хотел больше написать о том как меня восхетил rcbuild) Но проверил вариант на локальной машине. Условия отличаются от сервера, поэтому не считаю этот эксперимент достаточно показательным, но предварительными результатами поделюсь.

Для maxParallelFileOps попробовал 1000, 256 и 128 — по три запуска с heap 1280 MiB и ограничением до четырёх CPU. Медианы пикового RSS получились 1620, 1708 и 1701 MiB соответственно. Заметной экономии памяти к сожалению не увидел. Время сильно гуляло, в том числе на фоне другой нагрузки, поэтому выводов о скорости не делаю.

Про Cgroup почитаю, спасибо!

[AnnSerba]

Спасибо, что проверили. Отрицательный результат здесь полезнее моего предположения: если 128 и 1000 дают одинаковые 1620–1708 MiB, значит параллельное чтение файлов в пик вообще не вносит. По вашим же цифрам видно, где искать дальше: при heap 1280 суммарный RSS выше на 300–400 MiB, то есть заметная часть памяти живёт вне кучи. Гадать по ручкам после этого смысла мало — быстрее снять heap snapshot у предела: node --heapsnapshot-near-heap-limit=1 с запуском Vite, и в DevTools посмотреть retainer path у самых тяжёлых узлов. Там обычно сразу видно, это AST модулей или уже сгенерированные строки кода, и дальше решение принимается по факту.