Сколько RAM нужно для Gatsby

MAATRIX

Если на VPS с 1 ГБ RAM gatsby build падает с JavaScript heap out of memory — это не баг вашего проекта, а нормальное поведение Gatsby на скромном железе. Gatsby продают как «статический сайт, который летает у пользователя», и это правда для готовой страницы. Но сама сборка — это React, GraphQL-слой поверх всех данных и webpack с Sharp в придачу, и именно эта связка ест память, а не итоговый сайт. Разберём отдельно, сколько нужно на сборку, сколько на раздачу готовых файлов, и как измерить свой проект, а не гадать по чужим цифрам.

Сколько RAM нужно на сборку — по масштабу сайта

Официальной цифры «минимум для Gatsby» не существует — команда её не публикует, потому что зависимость слишком сильная от объёма контента, числа плагинов и картинок. Ориентируйтесь на масштаб своего проекта:

Это ориентир, а не измеренный бенчмарк — точная цифра зависит от числа плагинов, объёма данных из CMS и размера изображений. Надёжный способ узнать своё число — замерить (см. ниже).

Если сборка падает по памяти, а поднять тариф VPS сейчас не вариант, можно временно увеличить лимит V8 для Node:

NODE_OPTIONS="--max-old-space-size=4096" npx gatsby build

Это не добавляет физическую память — если её реально не хватает, процесс всё равно упадёт, просто получит сигнал OOM killer вместо аккуратной ошибки heap. Второй рычаг — переменная GATSBY_CPU_COUNT=2, которая заставляет Gatsby считать, что ядер меньше, чем есть на самом деле, снижая пиковое потребление памяти ценой скорости сборки. Полезно на VPS с 2+ ядрами и небольшим объёмом RAM, где параллельные worker'ы для GraphQL и картинок съедают память быстрее, чем успевают её освобождать.

GraphQL-слой и sourceNodes: где реально копится память

Отличие Gatsby от большинства статических генераторов — все данные сайта проходят через внутренний GraphQL data layer. Каждый файл, запись из CMS или элемент API превращается в ноду, и Gatsby строит по всем нодам единую схему, которую потом можно запрашивать в любом компоненте.

Начиная с Gatsby 4 часть внутреннего хранилища (Redux store с нодами) вынесена на диск через LMDB — embedded key-value хранилище — вместо того, чтобы держать всё исключительно в RAM, как раньше. Это заметно снизило пиковое потребление на крупных сайтах, но полностью проблему не убрало: схема, кэши резолверов и промежуточные результаты запросов на этапе сборки всё равно живут в памяти.

Практически это значит: чем больше источников данных и чем «жирнее» ноды (например, WordPress-посты с полным HTML-содержимым каждой записи вместо только нужных полей), тем больше памяти уходит на схему и резолвинг запросов. Частая ошибка в gatsby-node.js — запрашивать в createPages больше полей, чем реально нужно для генерации путей:

exports.createPages = async ({ graphql, actions }) => {
  const { createPage } = actions;
  const result = await graphql(`
    query { allWpPost { nodes { id slug } } }
  `);
  result.data.allWpPost.nodes.forEach((post) => {
    createPage({
      path: `/blog/${post.slug}/`,
      component: require.resolve('./src/templates/post.js'),
      context: { id: post.id },
    });
  });
};

Для путей на этапе createPages обычно нужны только id и slug — полный content лучше запрашивать внутри компонента страницы через pageQuery, где Gatsby резолвит его по одному на страницу, а не держит весь корпус контента в памяти разом.

Второй источник роста — плагины-источники, которые тянут слишком много за раз. Если gatsby-source-contentful или gatsby-source-wordpress настроены без пагинации, первая же синхронизация с крупным CMS может создать десятки тысяч нод и раздуть память ещё до генерации страниц.

Обработка изображений: gatsby-plugin-image и Sharp

Если сборка падает по памяти — в большинстве случаев виноваты картинки, а не страницы. gatsby-plugin-image вместе с gatsby-transformer-sharp и gatsby-plugin-sharp обрабатывает изображения во время сборки: генерирует несколько размеров и форматов (WebP, AVIF) под разные srcset, размывает placeholder, кроппит по нужным пропорциям.

Sharp — обёртка над libvips, экономная по памяти по сравнению с ImageMagick, но декодирование крупных исходников (фото с камеры на 15–30 МБ, 4K-скриншоты) всё равно требует места под несжатое изображение на время обработки. А если в gatsbyImageData настроено несколько breakpoints и форматов (formats: [AUTO, WEBP, AVIF]) — это несколько параллельных декодирований и кодирований на одну и ту же картинку. На каталоге в несколько сотен товарных фото пик легко уходит за гигабайт — точная цифра зависит от разрешения исходников и числа вариантов, не ориентируйтесь на чужие бенчмарки.

Что реально снижает нагрузку:

• Сжимайте исходники заранее — Sharp обрабатывает то, что вы ему даёте, и 30-мегабайтный TIFF не станет легче оттого, что на выходе просите 800px.
• Убирайте AVIF из списка форматов, если он не критичен — кодирование заметно тяжелее по памяти и CPU, чем WebP, при сопоставимом выигрыше в размере на большинстве фото.
• Ограничивайте число breakpoints до реально используемых в вёрстке — каждый лишний width это ещё один проход Sharp.
• Не удаляйте кэш .cache/ и обработанные изображения между сборками без нужды — Gatsby переиспользует их, если исходник не менялся, а холодный кэш пересчитывает всё заново. На CI кэш стоит сохранять как артефакт между запусками.

Продакшен: раздача готового сайта почти не требует памяти

Здесь Gatsby ничем не отличается от Hugo или статического Astro: после gatsby build в проде процесс Node.js для чисто статического сайта не нужен вообще. Всё содержимое папки public/ — готовые HTML-файлы, JS-бандлы, page-data/*.json и обработанные изображения — раздаёт обычный веб-сервер.

server {
    listen 80;
    server_name example.com;
    root /var/www/gatsby-site;
    index index.html;

    location / {
        try_files $uri $uri/ $uri.html /404.html;
    }

    location ~* ^/(static|page-data)/ {
        expires 1y;
        add_header Cache-Control "public, immutable";
    }
}

Nginx на такой раздаче ест единицы-десятки мегабайт вне зависимости от того, сколько страниц на сайте — разница только в объёме диска под public/. Отсюда практический вывод: считать RAM «под сайт» нужно не для продакшен-машины, а для той, где идёт сборка — это может быть тот же VPS, где крутится Nginx (сборка временно отъедает память у раздачи, и это нормально, если она короткая), или отдельный CI-раннер, который собирает статику и деплоит готовый public/ на прод. Полная схема деплоя — от установки Node.js и Gatsby CLI до автопересборки по вебхуку из CMS — разобрана в статье про деплой Gatsby на VPS; для автообновления по git-пушу без отдельного CI смотрите настройку автодеплоя из git.

Отдельная тема — режимы SSR (getServerData) и DSG (Deferred Static Generation), доступные начиная с Gatsby 4. Если часть страниц рендерится не на сборке, а по запросу — на проде снова нужен постоянно работающий Node.js процесс, память под который считается как для любого SSR-приложения: базовое потребление процесса плюс память на каждый одновременный запрос. Для большинства блогов и корпоративных сайтов эти режимы не нужны — чистая статика проще и дешевле по ресурсам.

Как измерить пик памяти на своём проекте

Не гадайте — замерьте. Системная утилита time с расширенным выводом (не встроенный в shell, а /usr/bin/time) показывает пиковый RSS процесса за всю сборку:

/usr/bin/time -v npx gatsby build 2>&1 | grep -i "maximum resident"
# Maximum resident set size (kbytes): 1 842 220

Если сборка идёт как systemd-юнит или таймер, точнее смотреть через cgroup: systemd-run --scope -p MemoryAccounting=yes --unit=gatsby-build npx gatsby build, затем cat /sys/fs/cgroup/system.slice/gatsby-build.scope/memory.peak — значение в байтах покажет максимум за всё выполнение, включая дочерние процессы Sharp и воркеры webpack.

Полезно замерить не только gatsby build, но и диск: node_modules у типичного Gatsby-проекта занимает от 300 МБ до гигабайта в зависимости от числа плагинов, а .cache/ и public/ растут вместе с сайтом (du -sh node_modules .cache public). На VPS с малым диском это стоит закладывать отдельно от RAM — нехватка места роняет сборку не менее эффективно, просто с другой ошибкой в логе. Общие подходы к нехватке памяти на сервере разобраны в статье что делать при нехватке RAM, своп как временная страховка — в материале про настройку swap-файла.

Какой сервер взять в MAATRIX под Gatsby

Честный минимум: 2 vCPU, 2 ГБ RAM, 20 ГБ NVMe. Подходит для лендинга или небольшого блога без тяжёлой обработки изображений на каждой сборке — сборка проходит, но без большого запаса на рост.

Комфортный вариант: 2–4 vCPU, 4 ГБ RAM, 40 ГБ NVMe. Наш обычный совет для сайта, который тянет данные из headless CMS, использует gatsby-plugin-image на каталоге фотографий и растёт числом страниц. Запас на пиковую сборку без риска задеть память, которой параллельно пользуется Nginx.

Если сайт крупный: 4 vCPU, 8 ГБ RAM, 80 ГБ NVMe. Тысячи страниц, десятки источников данных, регулярная пересборка по вебхуку из CMS. На таком масштабе вторым узким местом обычно становится CPU — GraphQL-резолверы и обработка изображений упираются в число ядер быстрее, чем в гигабайты памяти.

Если решили не собирать на проде вообще, а выносить сборку в CI и деплоить только готовый public/ — продакшен-машина может быть заметно скромнее, вплоть до 1 ГБ RAM: Nginx под статику почти ничего не просит.

Заказать сервер под Gatsby в MAATRIX можно за пару минут в личном кабинете — выбираете конфигурацию, ставите Ubuntu или Debian, дальше следуете инструкции по установке Node.js и деплою. Оплата из России — картой российского банка, по СБП, криптовалютой или токеном MAAT, без иностранной карты и посредников.

Частые вопросы