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

MAATRIX

Вопрос «сколько RAM нужно для Hugo» задают чаще всего не от незнания, а от недоверия к самой идее: генератор статики, который хвастается сборкой тысяч страниц за секунды, правда ли ему хватит одного гигабайта? Правда, но с оговоркой — Hugo написан на Go и почти ничего не весит сам по себе, а память съедают не шаблоны и не движок, а конкретные операции внутри сборки: обработка изображений, Hugo Modules и объём контента. Разберём по частям, сколько нужно на самом деле.

Короткий ответ: сколько RAM нужно для Hugo

Цифры для машины, которая занимается только сборкой сайта Hugo — без соседних сервисов.

Официальных требований к памяти у Hugo нет — проект не публикует цифру вроде «минимум 1 ГБ», потому что сам бинарник почти ничего не ест: статическая генерация на компилируемом языке без интерпретатора и без сборщика мусора уровня JVM держит сайт из нескольких тысяч Markdown-страниц без картинок в десятках-сотнях мегабайт RSS. Реальный вопрос не «хватит ли Hugo памяти», а «что именно в вашей сборке заставляет процесс расти» — и тут ответ почти всегда один: изображения.

Куда уходит память во время сборки: рендеринг и шаблоны

Hugo строит сайт в один проход: читает контент, разбирает front matter, применяет шаблоны и держит промежуточное представление сайта в памяти, пока не запишет public/. Это значит, что пик приходится на момент, когда в памяти одновременно находится дерево всех страниц, распарсенные шаблоны и результаты рендеринга, ещё не сброшенные на диск.

Проверить версию и режим сборки перед разбором:

hugo version
# hugo v0.150.0+extended linux/amd64 BuildDate=...

Строка +extended важна: расширенная сборка включает поддержку SCSS через LibSass-совместимый транспилятор и более широкий набор возможностей Hugo Pipes — без неё часть asset-функций просто недоступна, и это не про память, а про то, соберётся ли сайт вообще.

Шаблоны сами по себе память почти не расходуют, но есть исключение — тяжёлые операции над всем набором страниц внутри шаблона: .Site.RegularPages в цикле на каждой странице (списки «похожие статьи», сайдбар с «последними записями» на всех страницах разом), .Site.Taxonomies при большом числе тегов и категорий, вложенные partial с dict и slice, пересоздающие структуры данных вместо переиспользования через partialCached.

Профилировать медленные (и, как следствие, память расходующие) шаблоны можно встроенным флагом:

hugo --templateMetrics --templateMetricsHints

Команда печатает таблицу: сколько раз вызывался каждый шаблон и партиал и сколько суммарно занял. Партиалы с большим числом вызовов и без кеша — первые кандидаты на partialCached, который не только ускоряет сборку, но и снимает повторное выделение памяти под одинаковые данные.

Обработка изображений и Hugo Pipes — главный потребитель

Если сборка Hugo падает по памяти, в девяти случаях из десяти виноваты не страницы, а картинки. Hugo Pipes умеет ресайзить, кропать и конвертировать изображения прямо во время сборки — функциями вроде .Resize, .Fit, .Fill в шаблонах. Каждая такая операция декодирует исходное изображение в память целиком, обрабатывает и кодирует результат — и держит это в RAM, пока не сохранит в кеш.

Тяжелее всего два сценария: большие исходники (фотографии с камеры на 15–30 МБ) и много вариантов одного изображения (превью, retina, разные ширины для srcset). Пример шаблона, который съедает заметно больше памяти, чем кажется на вид:

{{ range .Resources.ByType "image" }}
  {{ $small := .Resize "400x" }}
  {{ $medium := .Resize "800x" }}
  {{ $large := .Resize "1600x" }}
  {{ $webp := .Resize "800x webp" }}
{{ end }}

Четыре варианта на каждое изображение — четыре декодирования плюс четыре результата в памяти одновременно, пока Hugo не запишет их в resources/_gen/images/. Точная цифра пика зависит от разрешения исходников и формата — ориентируйтесь не на число, а на факт: чем больше вариантов и крупнее исходники, тем выше пик.

Настройки, которые реально снижают расход:

[imaging]
  resampleFilter = "Linear"
  quality = 82
  anchor = "Smart"

resampleFilter = "Linear" заметно легче и быстрее, чем Lanczos по умолчанию (тот даёт более чистую картинку, но дороже по CPU и памяти). Второй и главный приём — кеш на диске: Hugo обрабатывает изображение один раз и складывает результат в resources/_gen/images/, при повторных сборках отдаёт готовый файл, если исходник не менялся. На CI это работает, только если кеш переживает между запусками — сохраняйте resources/_gen как артефакт, иначе каждая сборка пересчитывает всё заново. Флаг hugo --gc в конце сборки чистит неиспользуемые записи кеша на диске — на память во время самой сборки это не влияет, экономия дисковая.

Hugo Modules и большие сайты: тысячи страниц

Hugo Modules — способ подключать темы и компоненты через go.mod, а не через git submodule. Механизм удобный, но за кулисами использует Go-тулчейн, и первая сборка (или hugo mod get -u) тянет модули из сети и считает граф зависимостей — на это нужен отдельный запас памяти сверх самой сборки Hugo:

hugo mod init github.com/you/site
hugo mod get -u
HUGO_MODULE_VENDORING=1 hugo mod vendor

hugo mod vendor кладёт зависимости в _vendor/ внутри проекта — сборки после этого не ходят в сеть и не пересчитывают граф модулей каждый раз, что быстрее и предсказуемее по памяти на CI. Кеш модулей по умолчанию живёт в ~/.cache/hugo_cache/modules — на сервере с малым диском его стоит периодически чистить командой hugo mod clean.

С ростом сайта до нескольких тысяч страниц добавляется вторая статья расхода — related content. Функция .Site.RegularPages.Related строит в памяти индекс похожести по тегам, категориям и датам для всех страниц сразу:

[related]
  threshold = 80
  includeNewer = true

  [[related.indices]]
    name = "tags"
    weight = 100
  [[related.indices]]
    name = "categories"
    weight = 50

Индекс строится один раз за сборку и держится в памяти до конца — на сайте с 10 000+ страниц и активным тегированием это заметная, хоть и не катастрофическая добавка.

Как измерить пик памяти и не гадать

Проще всего — системная утилита time с расширенным выводом (не путать со встроенным в shell time, нужен /usr/bin/time):

/usr/bin/time -v hugo --minify --gc 2>&1 | grep -i "maximum resident"
# Maximum resident set size (kbytes): 412 316

Значение в килобайтах — это и есть пиковый RSS процесса hugo за всю сборку, самая честная цифра для сравнения с тарифом сервера.

Если Hugo собирается как systemd-сервис или из-под юнита (например, таймером для регулярной пересборки), точнее смотреть через cgroup:

systemd-run --scope -p MemoryAccounting=yes --unit=hugo-build \
  hugo --minify --gc --destination /var/www/site/public

cat /sys/fs/cgroup/system.slice/hugo-build.scope/memory.peak

memory.peak в байтах — максимум, который держал весь scope за время выполнения, включая дочерние процессы (актуально, если asset pipeline вызывает внешние бинарники вроде esbuild или postcss).

Третий способ — если сборка запускается в CI (Woodpecker, Drone, GitLab CI, Gitea Actions), сравнить лимит контейнера job с фактическим потреблением через docker stats. Падение сборки на CI с кодом выхода 137 и пустым логом от самого Hugo — почти всегда OOM: контейнеру не хватило памяти, а не баг в шаблоне. Если Hugo вообще не запускается или падает с другой ошибкой на сервере — это отдельная тема, разобранная в статье про частые ошибки Hugo на сервере.

Продакшен-сервер: сборка и раздача — разные нагрузки

Здесь Hugo принципиально отличается от WordPress, n8n или любого другого сервиса, для которого вы обычно считаете память под постоянно работающий процесс. У Hugo в продакшене процесс не работает постоянно вообще: hugo запускается, собирает статику в public/ и завершается. Раздачей занимается веб-сервер — Nginx или Caddy — который читает готовые HTML-файлы с диска и почти не расходует память вне зависимости от того, сколько страниц на сайте.

Отсюда практический вывод: считать RAM под Hugo нужно не для «сервера сайта», а для машины, где идёт сборка. Вариант первый — тот же VPS, где крутится Nginx: сборка временно отъедает память у раздачи, и это нормально, если она короткая и не совпадает с пиком трафика. Вариант второй, чище — отдельный CI-раннер (Woodpecker, Gitea Actions), который собирает статику и деплоит готовый public/ на продакшен-сервер по rsync или webhook: раздающая машина не падает, даже если сборка временно раздулась на картинках, и может быть совсем скромной. Как собрать саму связку — от установки Hugo до автодеплоя через git-хук — подробно описано в статье про установку и настройку Hugo на VPS и в материале про Hugo: статический сайт, установка и деплой.

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

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

Комфортный вариант: 2 vCPU, 2 ГБ RAM, 40 ГБ NVMe. Наш обычный совет для сайта с Hugo Modules, галереей изображений и asset pipeline (PostCSS, esbuild). Запас на пиковую сборку без риска зацепить память, которой пользуется Nginx для раздачи уже готовых страниц.

Если сайт растёт: 4 vCPU, 4 ГБ RAM, 80 ГБ NVMe. Десятки тысяч страниц, регулярная пересборка галерей, отдельный CI-раннер на этой же машине. Дороже — не по памяти, а по CPU: параллельный рендеринг страниц Hugo упирается в число ядер быстрее, чем в RAM, поэтому на действительно больших сайтах вторым узким местом станет GOMAXPROCS, а не гигабайты.

Диск на статическом сайте почти всегда важнее второго гигабайта памяти: изображения, кеш resources/_gen и Git-история контента занимают заметно больше места, чем сама сборка — закладывайте запас NVMe с учётом роста медиатеки.

Локация — выбирайте по аудитории сайта, а не по самой сборке: Hugo одинаково быстро соберётся что в России, что в Лондоне, поскольку вся работа локальная и в сеть ходит только hugo mod get за модулями. Сравнение вариантов под хостинг сайтов — в статье лучший VPS для хостинга сайтов.

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

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