Этот трюк с Linux останавливает сбои Next.js.

Вы запускаете `next build` на новом дроплете Ubuntu, и всё выглядит хорошо в течение примерно 10 секунд. Затем нагрузка резко возрастает, процессор работает на 100%, и ваша SSH-сессия начинает терять символы, как на плохом звонке в Zoom. Через минуту терминал возвращается с единственным, раздражающим словом: “Убито.”

Никакого стека вызовов, никаких аккуратных кодов ошибок, просто мёртвый билд. Запустите его снова, и вы увидите ту же картину: вентиляторы начинают работать на полную мощность, вверху отображается Node, и рой рабочих процессов жует ЦП, затем тишина. Если вы посмотрите графики вашего провайдера после этого, вы увидите резкий всплеск использования ЦП и памяти, за которым следует обрыв, где ваш процесс исчез.

Этот режим отказа особенно сильно отражается на дешевых местах в облаке. Эти экземпляры за $5–$7 в месяц с 1 ГБ ОЗУ от DigitalOcean, Vultr, Linode или Lightsail идеально подходят для базового Node-приложения — пока не попросите их выполнить современную Next.js сборку. Во время этого процесса ваш «маленький, но мощный» дроплет внезапно ведет себя как Raspberry Pi, пытающийся скомпилировать Chrome.

Разработчики обычно встречают это с самым дорогим рефлексом в облачных вычислениях: предполагают, что проблема в оборудовании. История повторяется каждый раз. Сборка зависает, сервер кажется замороженным, и инстинктивная реакция: «Эта коробка просто не может справиться с Next.js. Мне нужно 2 ГБ, может быть, 4 ГБ».

Облачные панели даже подталкивают вас к этому. Вы видите, что память заполнена, процессор на пределе, и в логах отображается красное событие «недостаточно памяти». Кнопка обновления находится в одном клике, обещая, что более высокий уровень экземпляра заставит проблему исчезнуть. Для многих команд этот клик становится частью плейбука развертывания.

Реальность менее гламурна и стоимость её гораздо ниже. Эти сбои не обязательно означают, что вашему приложению нужна постоянная более мощная машина; они указывают на то, что на этапе сборки требуется немного больше памяти, чем у вашего дропа доступно. И на стандартном образе Ubuntu с отключённым swap у ядра есть только один надежный способ справиться с этой нагрузкой: завершить вашу сборку.

Next.js выглядит как один процесс `node` в `htop`, но `next build` ведет себя скорее как маленькая распределенная система, упакованная в один бинарный файл. За кулисами Next.js управляет несколькими рабочими процессами Node, инструментарием TypeScript, сборщиком и конвейерами для ассетов, все борющиеся за один и тот же ограниченный 1 ГБ ОЗУ.

Начните с самого Node. Главный процесс запускает несколько рабочих потоков или дочерних процессов, чтобы параллелизировать компиляцию страниц. Каждый рабочий поток загружает свой собственный фрагмент графа зависимостей, кучи V8 и метаданные сборки. Вместо одного процесса размером 200–300 МБ вы получаете несколько, и их пиковые нагрузки накладываются друг на друга.

Далее, история о TypeScript. Когда вы запускаете `next build` в проекте на TypeScript, инструментарий загружает компилятор TypeScript, разбирает вашу полную кодовую базу и выполняет проверку типов. Это означает, что в памяти одновременно находятся несколько больших AST, таблиц символов и кэшей, что часто приводит к увеличению использования памяти до сотен мегабайт в проектах среднего размера.

Кроме того, Next.js вызывает сборщик (Webpack или Turbopack) для генерации как клиентских, так и серверных сборок. Каждая цель требует собственного графа зависимостей, проходов оптимизации и карт исходников. Большие библиотеки компонентов, UI-фреймворки и дизайн-системы раздувают эти графы, поэтому проект, который работает нормально на 300–400 МБ в производстве, может достигать 800–900 МБ или более во время сборки.

Затем идут изображения и статические активы. Когда вы включаете next/image или обрабатываете большие медиафайлы, конвейер сборки декодирует, изменяет размер и перекодирует файлы. Операции с изображениями требуют значительных ресурсов памяти: несколько 4K-изображений или спрайт-листов могут временно занимать десятки или сотни мегабайт для каждого worker, прежде чем будут записаны обратно на диск.

Все это происходит в узком временном интервале от нескольких секунд до нескольких минут. Представьте себе кофейню на 20 мест, которая внезапно принимает флешмоб на 60 человек. Обычный поток клиентов работает нормально, но этот короткий, хаотичный всплеск блокирует дверные проходы, перегружает сотрудников и оставляет постоянных клиентов снаружи. `next build` создает именно такой временной перегруз на 1 ГБ дроплете.

На сервере с 1 ГБ Ubuntu и без обмена эта флеш-акция превышает физический лимит использования памяти. Ядро начинает активно освобождать память, кэши исчезают, и когда все еще не удается найти достаточное количество ОЗУ, на помощь приходит OOM-убийца, который завершает самые ресурсоемкие процессы. Ваша `следующая сборка` умирает с однословным надгробием: `Убито`.

OOM-убийца звучит драматично, потому что это так. Когда система Linux исчерпывает физическую оперативную память, OOM-убийца ядра вступает в действие как последний рубеж безопасности, сканируя каждый запущенный процесс и решая, какой из них пожертвовать, чтобы вся машина не зависла. Без него 1-гигабайтный дроплет Ubuntu под давлением памяти просто замерзнет, прервав SSH-сессии и оставив вас с мёртвым терминалом и принудительной перезагрузкой.

Сборки Next.js становятся идеальными целями. Во время `next build` Node создает несколько рабочих процессов, загружает компиляторы, такие как TypeScript, обрабатывает пакеты и иногда занимается обработкой изображений, легко увеличивая использование памяти на сотни мегабайт выше базового уровня на короткий промежуток времени. Для ядра это выглядит как крупный, недавний и несущественный процесс, который можно завершить с минимальным "системным" воздействием.

Linux использует эвристику под названием oom_score (и oom_score_adj) для ранжирования жертв. Крупные процессы, которые недавно выделили много памяти, не работают от имени пользователя root и не относятся к основным службам системы, поднимаются на верхние позиции. Сборка Next.js на дроплете с 1 ГБ ОЗУ, которая уже находится рядом с nginx, sshd и, возможно, небольшой базой данных, часто становится самым "жирным" и выбрасываемым объектом в оперативной памяти.

Никакая своп-память полностью не меняет ситуацию. Когда оперативная память достигает 100%, а своп не настроен, у ядра есть только два варианта: зависнуть, отчаянно пытаясь вернуть страницы, или вызвать OOM-убийцу. Этот бинарный выбор объясняет, почему ваш терминал зависает на некоторое время, а затем выдает одно слово — “Убито” — без следа стека, без ошибки Next.js и без полезных подсказок от Node.

Эта строка «Убито» не является проявлением грубости со стороны npm; это подпись ядра. Вы увидите её при неудачных запусках `pnpm install`, `npm install` или `next build`, когда OOM-убийца завершает процесс в разгаре работы. Системные журналы (`dmesg` или `journalctl -k`) обычно раскрывают истину с записями вроде «Недостаточно памяти: Убить процесс 1234 (node) с баллом 900 или пожертвовать потомком».

Swap предоставляет ядру еще один ход. Даже с файлом подкачки объемом 1–2 ГБ система может выгружать неактивные страницы — бездействующие демоны, кэшированные страницы, редко используемые библиотеки — на диск, освобождая ОЗУ, чтобы сборка завершилась вместо того, чтобы быть прерванной. Для получения пошаговых инструкций ресурсы, такие как Как создать файл подкачки для развертывания приложения NextJS и Docker на Ubuntu VPS, предлагают настройку, удобную для производства.

Своп-пространство работает как предохранительный клапан для памяти вашего маленького сервера. Вместо того чтобы сразу завершить процесс `next build`, когда ОЗУ достигает 100%, ядро Linux может сбрасывать избыточные данные в выделенный участок диска и продолжать работу. Этот участок — это ваш своп-файл.

Думайте о свопе как о «дополнительной оперативной памяти», которая находится на носителе, а не в кремнии. Linux выделяет файл или раздел на диске и рассматривает его как продолжение физической памяти, измеряемой в тех же 4 КБ страницах, что и обычная оперативная память.

Когда ваш 1 ГБ дроплет исчерпывает оперативную память во время сборки Next.js, ядро начинает процесс аварийного завершения. Страницы, принадлежащие неактивным демонам, старым кэшам или фоновым сервисам, перемещаются из оперативной памяти в файл swap, освобождая реальную память для активных кодовых путей сборки.

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

Диск медленнее по сравнению с ОЗУ — миллисекунды вместо наносекунд — поэтому использование свопа всегда добавляет задержку. Однако для краткосрочной сборки стабильность важнее скорости: сборка `next build`, которая завершается за 90 секунд на сервере с использованием свопа, гораздо лучше, чем одна, которая просто останавливается через 20 секунд с единственным словом "Убито".

На сервере с настроенным свопом тот же самый резкий всплеск памяти выглядит скучным. Процессор всё равно нагружается, вентиляторы продолжают работать, но ваша SSH-сессия остаётся отзывчивой, `top` показывает растущее использование свопа, и сборка продолжается вместо того, чтобы разрушить таблицу процессов.

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

Этот контраст очевиден: с использованием swap, сборки кажутся тяжелыми, но надежными; без него та же нагрузка может зависнуть в вашей оболочке, испортить развертывание и заставить вас караулить перезагрузку дроплета.

Начните с проверки, есть ли у вашего Ubuntu компьютера swap. Выполните команду `sudo swapon --show`. Пустой результат означает, что нет активных swap-устройств. Затем выполните `free -h`, чтобы увидеть общий объем ОЗУ и текущий swap, а затем `df -h`, чтобы проверить использование диска. На типичном дроплете объемом 25 ГБ вы обычно увидите, что используется менее 20%, что оставляет достаточно места для файла swap размером 2 ГБ.

После подтверждения дискового пространства выделите файл подкачки. Для сервера с 1 ГБ оперативной памяти файл размером 2 ГБ предоставит сборкам Next.js реальное пространство для маневра, не перегружая диск. Используйте команду `sudo fallocate -l 2G /swapfile`. Это резервирует 2 ГБ мгновенно, не записывая нули. Проверьте это с помощью `ls -lh /swapfile`, и вы должны увидеть `2.0G` в столбце размера.

Прямо сейчас `/swapfile` — это обычный файл, к которому может получить доступ любой. Ограничьте доступ, чтобы только root мог читать или записывать в него. Выполните `sudo chmod 600 /swapfile`. Проверьте права доступа снова с помощью `ls -lh /swapfile`, и вы должны увидеть `-rw-------` в начале строки, что подтверждает, что файл является приватным для root.

Затем превратите этот простой файл в настоящую обменную память. Используйте команду `sudo mkswap /swapfile`. Ubuntu ответит сообщением вроде `настройка пространства подкачки версия 1, размер = 2 ГиБ`. Это сообщение означает, что ядро теперь распознает `/swapfile` как допустимую область подкачки, но она все еще неактивна, пока вы не включите ее явно.

Активируйте своп одной командой: `sudo swapon /swapfile`. Затем снова выполните команду `sudo swapon --show`, и вы должны увидеть таблицу, в которой указано `/swapfile`, его размер (примерно `2G`) и приоритет. Также команда `free -h` покажет `Swap: 2.0Gi` в сводке, подтверждая, что ядро теперь может выгружать страницы памяти, когда нагрузки на Next.js увеличиваются.

В данный момент эта конфигурация сохраняется после перезагрузки только в случае, если вы сделаете её постоянной. Отредактируйте файл `/etc/fstab`, используя команду `sudo nano /etc/fstab`, и добавьте одну строку внизу:

- `/swapfile none обмен sw 0 0`

Сохраните, выйдите, и всё готово. При следующей перезагрузке Ubuntu автоматически активирует `/swapfile`, так что ваши сборки Next.js продолжат работать даже после обновлений ядра, перезагрузок или неожиданных сбоев.

Созданный вами своп существует только до текущей загрузки. Команда `swapon /swapfile` переключает режим выполнения; как только ядро перезагружается, это состояние исчезает, и ваши сборки Next.js снова заканчиваются с сообщением `Killed`.

Чтобы сохранить swap в активном состоянии после перезагрузки, необходимо зарегистрировать его в файле `/etc/fstab`, который система Linux считывает при загрузке. Этот файл указывает ядру, какие диски, разделы и swap области монтировать автоматически.

Перед тем как вносить изменения, сделайте резервную копию. Испорченный `/etc/fstab` может остановить загрузку сервера, оставив вас в поисках консоли восстановления на вашем облачном панеле управления.

Беги:

- `sudo cp /etc/fstab /etc/fstab.bak`

Теперь откройте файл с помощью редактора с правами администратора, например:

- `sudo nano /etc/fstab`

Прокрутите вниз и добавьте эту точную строку:

- `/swapfile none swap sw 0 0`

Каждое поле имеет значение. `/swapfile` — это путь к вашему файлу подкачки. `none` обозначает точку монтирования, потому что подкачка не монтируется в дерево каталогов.

`swap` объявляет тип файловой системы, что сообщает ядру, что эта запись является виртуальной памятью, а не ext4 или xfs. `sw` — это установленный параметр монтирования, сокращенный вариант “обрабатывать это как своп с поведением по умолчанию.”

Последние два нуля управляют поведением `dump` и `fsck`. `0 0` означает, что система не будет пытаться создать дамп или выполнять проверки файловой системы для этого файла, что именно и требуется для раздела подкачки.

После сохранения проверьте синтаксис с помощью:

- `sudo mount -a`

Отсутствие вывода обычно означает успех. Перезагрузите систему с помощью `sudo reboot`, затем подтвердите постоянство с помощью `free -h` или `swapon --show`. Для более глубокой настройки и информации о производительности свопа смотрите Ускорьте свою систему Linux с помощью пространства свопа - Kite Metric.

Swap ведет себя как клапан давления для оперативной памяти, а не как бесплатное улучшение производительности. При осторожном использовании он позволяет крошечному объему в 1 ГБ оставаться активным достаточно долго, чтобы завершить сборки Next.js. При неосторожном использовании он может полностью остановить работу производственного приложения.

Когда использовать swap: кратковременные, резкие всплески памяти. Выполнение `next build`, которое длится 2–5 минут и кратковременно увеличивает использование с 700–800 МБ до 1.3–1.5 ГБ, идеально подходит. Ядро может выгнать холодные страницы на диск, освободив несколько сотен мегабайтов, и ваша сборка завершится вместо того, чтобы быть "Убита".

Тем же правилам подчиняются и другие задачи с периодическим исполнением, которые выполняются редко и не обслуживают живой трафик. Хорошие кандидаты включают: - `npm install`, `pnpm install` или `yarn install` - Миграции баз данных или разовые импорт данных - Периодические администраторские или служебные скрипты - Шаги при развертывании в контейнерах или CI-агентах

В таких случаях ваше приложение использует значительно меньше физической оперативной памяти — скажем, 300–500 МБ на сервере с 1 ГБ — и нуждается в дополнительном пространстве лишь во время сборок или установок. Вы жертвуете немного скоростью ради надежности: сборка может выполняться на 20–40% медленнее при использовании swap, но на самом деле завершается. Для многих команд оставаться на меньшем дроплете сразу компенсирует эти затраты.

Когда не стоит использовать своп: постоянное давление на память от вашего основного приложения. Если ваш сервер Next.js и база данных вместе требуют 1,4 ГБ на экземпляре в 1 ГБ в течение всего дня, ядро постоянно перемещает страницы памяти между ОЗУ и диском. Это трепетание разрушает производительность, потому что диск, даже SSD, на порядок медленнее, чем ОЗУ.

Вы можете заметить вредный свопинг по нескольким конкретным симптомам: - Высокая дисковая нагрузка I/O (`iostat`, `iotop`) даже при низком объеме запросов - Медленные HTTP-ответы или тайм-ауты даже при небольшом количестве пользователей - Команда `free -h` показывает сотни мегабайт используемого свопа, который едва снижается в режиме простоя - Пиковая нагрузка при среднем уровне использования процессора, который остается странно скромным

Если эти тревожные сигналы появятся, использование свопа будет похоже на пластырь на пулевую рану. Настоящее решение — это больше оперативной памяти или более строгие бюджетные ограничения по памяти: сократите количество рабочих процессов Node, уменьшите размеры кэша, разделите сервисы или переместите базу данных на отдельный сервер. Своп должен справляться с редкими всплесками, а не поддерживать ваше приложение 24/7.

Swap дает вам свободу действий, но еще один тихий саботажник все равно может разрушить вашу сборку: Node.js сам по себе. Если Node решает, что ему нужно 8 ГБ кучи на сервере с 1 ГБ ОЗУ, никакие магические трюки со свопом не спасут вас от убийцы OOM. Именно здесь один скрытый флаг меняет все.

Флаг `--max-old-space-size` в Node контролирует, сколько памяти движок V8 может использовать для своей основной кучи JavaScript, измеряемой в мегабайтах. Когда этот лимит установлен слишком высоко, Node активно резервирует память, которой у вашего устройства просто нет, и ядро отвечает, убивая процесс, как только ОЗУ + своп исчерпываются.

Проекты Next.js часто скрывают эту ловушку в файле `package.json`. Погружаясь в раздел `scripts`, вы можете увидеть команду сборки, такую как: - `"build": "NODE_OPTIONS='--max-old-space-size=8192' next build"`

На дроплете с 1 ГБ памяти целевой размер кучи в 8192 МБ — это фантазия. Node с радостью попытается достичь этой отметки, однако ваши 1 ГБ ОЗУ и, возможно, 1-2 ГБ подкачки испарятся, и ваша сборка завершится с тем же резким сообщением `Killed`, с которого вы начали.

Первый шаг: откройте `package.json` вашего проекта и внимательно просмотрите все скрипты, связанные со сборкой. Ищите что-либо, что устанавливает `NODE_OPTIONS` или напрямую передает `--max-old-space-size` команде `node` или `next`, например: - `"build": "NODE_OPTIONS='--max-old-space-size=4096' next build"` - `"build": "node --max-old-space-size=6144 node_modules/next/dist/bin/next build"`

Затем согласуйте это число с вашим фактическим бюджетом: физическая ОЗУ + своп, минус накладные расходы на ОС, базу данных и фоновые сервисы. На сервере с 1 ГБ оперативной памяти и 2 ГБ файла подкачки (примерно 3 ГБ в сумме) ограничение `--max-old-space-size=2048` обычно имеет смысл и оставляет запас для всего остального.

Обновите скрипт, переустановите или разверните его заново и снова запустите `next build`. При включенном свопе и ограниченной памяти Node на реалистичном уровне ваши сборки перестанут притворяться, что работают на рабочей станции с 64 ГБ, и начнут вести себя так, как будто живут на тесном, недорогом сервере.

Swap тихо исправляет не только ненадежные сборки Next.js. Любая задача, которая время от времени вызывает всплески использования памяти на небольшом VPS или рабочей станции разработчика, выигрывает от наличия нескольких дополнительных гигабайтов виртуальной памяти, на которую можно опираться, вместо того чтобы столкнуться с OOM-убийцей.

Менеджеры пакетов часто становятся виновниками этой проблемы. Один-единственный `npm install`, `pnpm install` или `yarn install` в современном монорепозитории может запустить десятки рабочих процессов Node, распаковать тысячи архивов и вычислить деревья зависимостей в памяти. На сервере с 1 ГБ ОЗУ это может легко привести к использованию более 90-100% RAM в течение нескольких минут.

Тяжелые скрипты импорта данных и миграции ведут себя одинаково. ETL-задания, которые загружают в память несколько сотен мегабайтов JSON или CSV, миграции Prisma или TypeORM, которые заполняют большие схемы, или ад-хок администраторские скрипты, которые пакетно обрабатывают записи пользователей, все создают кратковременные и резкие всплески памяти. При включенном свопе эти всплески замедляют процесс вместо того, чтобы разорвать ваше SSH-соединение.

Инструменты работы с базами данных также зависят от оперативной памяти. Запуск команды `pg_restore` на многогигбайтной дампе PostgreSQL, импорт снимка MySQL или выполнение повторного индексирования в Elasticsearch могут временно выделять сотни мегабайт буферов и кэшей. Файл подкачки объемом 1–2 ГБ дает ядру возможность оставлять неактивные страницы, в то время как активный код остается в реальной оперативной памяти.

Контейнеризованные среды добавляют еще один уровень хрупкости. Docker-контейнер, собирающий приложение Next.js, компилирующий нативные модули или выполняющий тесты, может достичь лимита памяти cgroup намного раньше, чем хост. Своп пространство на уровне хоста часто служит последним буфером, который не позволяет ядру завершить контейнер в процессе сборки.

Локальная разработка тоже не защищена. Запуск `next dev`, Storybook, базы данных и браузера с множеством вкладок на ноутбуке с 8 ГБ оперативной памяти может быстро исчерпать ресурсы. Сочетание небольшого файла подкачки с рекомендациями из статьи Как оптимизировать вашу локальную среду разработки - Next.js позволяет вашему компьютеру оставаться отзывчивым во время компиляции всего.

Проблемы с памятью на небольших серверах редко требуют более крупной кредитной карты. Им нужно диагностическое исследование. Прежде чем переходить с капли за $5 в месяц с 1 ГБ на экземпляр за $20 в месяц, проверьте, не связаны ли сборки Next.js с резким увеличением потребления памяти или постоянной, медленной утечкой.

Простой ментальный потоковый диаграмм помогает сохранять честность:

- Происходит ли сбой только во время кратковременных, редких задач (сборки Next.js, `npm install`, миграции)? → Сначала добавьте swap, затем повторите задачу. - Кажется ли сервер медленным во время обычного трафика, при высоком использовании swap и увеличенной задержке? → Проведите профилирование памяти, оптимизируйте запросы и кэши или увеличьте объем RAM. - Остается ли использование swap высоким даже когда приложение "в холостом режиме"? → Вы замаскировали настоящую проблему с пропускной способностью, а не решили ее.

Для прерывистых нагрузок файл подкачки объемом 1–2 ГБ на системе с 1 ГБ ОЗУ часто предотвращает активацию OOM-убийцы, благодаря чему ваша сборка действительно завершается. Вы жертвуете несколькими дополнительными секундами или минутами времени сборки ради успешного завершения. Это хорошая сделка, когда развертывания происходят несколько раз в день, а не тысячи раз в секунду.

Математика затрат делает аргумент жестким и четким. Оставаясь на экземпляре за $5 в месяц вместо перехода на $15, вы экономите $10 каждый месяц, или $120 в год на каждом сервере. Умножив это на 5 небольших сервисов, вы сохраните $600 в год в своем кармане за цену единовременной команды `fallocate` и строки в `/etc/fstab`.

Умное масштабирование означает использование инструментов, а не рефлект購ия на покупку больших серверов. Используйте swap для обработки редких всплесков, настраивайте флаги памяти Node.js, когда сборки всё ещё ведут себя неправильно, и только после этого переходите на более высокий уровень, когда ваше стабильное использование докажет, что это действительно необходимо.

Вы в конечном итоге получаете инфраструктуру, которую понимаете, а не которую боитесь. Когда сборка завершается со статусом «Убито», вы знаете, что нужно проверить память, область подкачки и ограничения Node.js, прежде чем открывать страницу ценообразования вашего облачного провайдера. Это знание превращает масштабирование из панического шага в обдуманный и экономически эффективный выбор.

Почему сборки Next.js используют так много памяти?

Сборки Next.js требуют большого объема памяти, поскольку они запускают несколько рабочих процессов для компиляции TypeScript, сборки клиентского и серверного кода, а также одновременной обработки ресурсов, таких как изображения. Этот короткий, но интенсивный всплеск активности может легко перегрузить серверы с ограниченной оперативной памятью, такие как облачные капли на 1 ГБ.

Использование файла подкачки в Linux негативно сказывается на производительности?

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

Сколько swap-пространства мне нужно добавить для сборки Next.js?

Хорошее общее правило для небольшого сервера (1-2 ГБ ОЗУ) — добавить пространство под своп, равное или вдвое превышающее объем физической ОЗУ. Для капли с 1 ГБ создание файла своп размером 1-2 ГБ обычно бывает достаточным, чтобы справиться с перепадами памяти во время сборки Next.js.

Могу ли я использовать своп вместо увеличения ОЗУ сервера?

Вы можете использовать своп, чтобы избежать обновления, если проблемы с памятью вызваны временными всплесками (например, при сборках или установках пакетов). Если повседневное использование памяти вашим приложением постоянно превышает объем ОЗУ вашего сервера, вам следует увеличить объем ОЗУ, так как полагание на своп для производственного трафика приведет к плохой производительности.