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

MAATRIX

MinIO — самый популярный способ поднять свой S3 без AWS: приложения, которые умеют работать с объектным хранилищем через S3 API, подключаются к нему как к обычному бакету, а данные при этом остаются на вашем сервере. Вопрос "сколько нужно RAM" здесь коварнее, чем кажется: сам процесс MinIO ест немного, но операционная система вокруг него — кеш файловой системы, буферы сети, параллельные запросы — съедает памяти на порядок больше, чем показывает ps aux. Разберём, откуда берётся расход и как посчитать RAM под свою нагрузку.

Из чего складывается расход памяти MinIO

Сам бинарник MinIO — это Go-приложение, и в простое оно действительно занимает немного: 150-400 МБ на процесс в зависимости от версии и числа дисков. Но реальный расход памяти на сервере с MinIO почти никогда не сводится к этой цифре, потому что память уходит по нескольким каналам одновременно.

• Базовый процесс — метаданные бакетов, политики доступа, кеш конфигурации IAM. Растёт слабо даже при большом количестве объектов, потому что MinIO не держит полный индекс объектов в памяти (в отличие, например, от некоторых NoSQL хранилищ) — он опирается на файловую систему как источник истины.
• Буферы на запрос — каждая активная загрузка или скачивание объекта требует буфера чтения/записи. По умолчанию это десятки МБ на соединение, и при 50-100 одновременных запросах суммарный расход легко доходит до 1-2 ГБ.
• Multipart upload — при загрузке больших файлов частями (стандартная практика для файлов от 100 МБ) MinIO держит в памяти части, пока не соберёт их в финальный объект. Один активный multipart upload с частями по 16-64 МБ может занимать сотни МБ.
• Кеш файловой системы Linux — вот где прячется основной расход. Linux агрессивно кеширует прочитанные с диска файлы в свободной RAM (page cache), и MinIO этим пользуется: повторное чтение "горячих" объектов идёт из памяти, а не с диска. Это не утечка — ядро отдаст эту память любому процессу, которому она понадобится, — но именно поэтому free -h на сервере с MinIO часто показывает почти всю RAM занятой.
• Erasure coding и scrubbing — при мультидисковой конфигурации с erasure coding (аналог RAID на уровне объектов) фоновая проверка целостности (mc admin heal) и восстановление после сбоя диска добавляют нагрузку на CPU и временный расход памяти на буферы кодирования.

Минимальная конфигурация: один узел для бэкапов и небольших проектов

Если вам нужен MinIO как приёмник для бэкапов, объектное хранилище для одного приложения (например, для загрузки пользовательских файлов через S3 API) или локальная замена S3 в CI/CD-пайплайне — хватает скромного сервера.

На таком узле имеет смысл запускать MinIO в single-node single-drive режиме — без erasure coding, с одним диском под данными. Это самый простой вариант развёртывания:

docker run -d --name minio \
  -p 9000:9000 -p 9001:9001 \
  -e "MINIO_ROOT_USER=admin" \
  -e "MINIO_ROOT_PASSWORD=ваш-надежный-пароль" \
  -v /opt/minio/data:/data \
  quay.io/minio/minio server /data --console-address ":9001"

Из ограничений: без RAID или erasure coding вы теряете защиту от сбоя диска на уровне самого MinIO — при выходе диска из строя данные восстанавливаются только из бэкапа. Для некритичных задач (кеш, временные файлы, зеркало бэкапов, которые и так лежат в другом месте) это осознанный компромисс, который экономит и RAM, и диски. Подробнее о том, какой объём диска закладывать с запасом, разобрано в статье про дисковое пространство с запасом.

Продакшен: сколько RAM под реальную нагрузку с S3 API

Если MinIO обслуживает продакшен-трафик — например, за ним стоит фронтенд, который активно грузит и отдаёт файлы (медиа, документы, экспорты отчётов), — расчёт RAM нужно вести не от объёма данных, а от параллелизма запросов.

Практический ориентир (это именно ориентир, а не измеренный бенчмарк — у вас цифры будут отличаться в зависимости от размера объектов и профиля нагрузки):

• 8 ГБ RAM — комфортно для 20-50 одновременных запросов на чтение/запись при объектах среднего размера (1-50 МБ). Подходит для небольшого SaaS-проекта или внутреннего сервиса компании.
• 16 ГБ RAM — запас для 100+ параллельных подключений, активного multipart upload больших файлов и разумного page cache для ускорения повторных чтений.
• 32 ГБ и больше — если MinIO обслуживает несколько приложений одновременно, либо среди клиентов есть аналитика/бэкап-системы, которые гоняют большие объёмы данных пачками.

Важный нюанс: MinIO сам по себе не требует много RAM для *хранения* объектов — это не in-memory база. Расход растёт от количества одновременных активных операций, а не от общего объёма данных в бакетах. Хранилище на 10 ТБ с низким трафиком спокойно живёт на 4-8 ГБ RAM, а хранилище на 500 ГБ с сотней активных клиентов потребует значительно больше.

Erasure coding и мультидисковые кластеры

Erasure coding — это способ MinIO защититься от потери диска без классического RAID: данные разбиваются на части с избыточностью, и кластер переживает потерю части дисков без потери данных. Это увеличивает требования к RAM и CPU, потому что кодирование/декодирование данных происходит на лету при каждой операции записи и чтения.

Типичная схема для среднего проекта — 4 диска на узел с настройкой EC:2 (переживает потерю 2 из 4 дисков):

docker run -d --name minio \
  -p 9000:9000 -p 9001:9001 \
  -e "MINIO_ROOT_USER=admin" \
  -e "MINIO_ROOT_PASSWORD=ваш-надежный-пароль" \
  -v /opt/minio/disk1:/data1 \
  -v /opt/minio/disk2:/data2 \
  -v /opt/minio/disk3:/data3 \
  -v /opt/minio/disk4:/data4 \
  quay.io/minio/minio server /data{1...4} --console-address ":9001"

Для такой конфигурации разумный минимум — 16 ГБ RAM на узел, а при активном фоновом scrubbing (проверке целостности данных, mc admin heal по расписанию) лучше закладывать 24-32 ГБ, особенно если диски — не NVMe, а HDD, где операции чтения для проверки идут медленнее и дольше держат буферы в памяти.

Для распределённого MinIO (несколько физических серверов в одном кластере с erasure coding между узлами) расчёт RAM идёт по тем же принципам на каждый узел отдельно — кластер не требует условной "общей" памяти сверх суммы узлов, но требует стабильной сети между ними с низкой задержкой, иначе кодирование данных станет узким местом раньше, чем память.

Docker vs bare metal: разница в накладных расходах

MinIO одинаково хорошо работает и как systemd-сервис на голом сервере, и в контейнере — разница в потреблении памяти минимальна (Docker добавляет 20-50 МБ накладных расходов на контейнер, что несущественно на фоне остальных цифр). Выбор в пользу Docker обычно делают ради удобства обновлений и изоляции, а не ради экономии ресурсов.

Что действительно важно настроить в контейнерном варианте — это лимиты памяти, чтобы MinIO не конкурировал за RAM с другими сервисами на том же хосте:

services:
  minio:
    image: quay.io/minio/minio:latest
    command: server /data --console-address ":9001"
    environment:
      MINIO_ROOT_USER: admin
      MINIO_ROOT_PASSWORD: ваш-надежный-пароль
    volumes:
      - minio-data:/data
    ports:
      - "9000:9000"
      - "9001:9001"
    deploy:
      resources:
        limits:
          memory: 8G
        reservations:
          memory: 2G
    restart: unless-stopped

volumes:
  minio-data:

Здесь важно не пережать лимит: если выставить memory: 2G на узел, который реально нагружен 50+ параллельными запросами, MinIO не упадёт сразу, но начнёт агрессивно выталкивать page cache, и производительность чтения заметно просядет — данные будут читаться с диска каждый раз вместо кеша. Общий подход к лимитам ресурсов в Docker разобран в статье про лимиты CPU и памяти в Docker.

MinIO рядом с другими сервисами: конкуренция за память

Частый сценарий — MinIO живёт не один на сервере, а рядом с приложением, базой данных или CI/CD-раннером, который в него же и складывает артефакты. Здесь легко недооценить суммарный расход, потому что каждый сервис по отдельности "укладывается" в свои гигабайты, а вместе они начинают конкурировать за page cache и вытеснять друг друга.

Практический подход — считать не сумму минимумов, а сумму рабочих пиков плюс запас:

• MinIO под бэкапы (2-4 ГБ) + PostgreSQL (2-4 ГБ) + веб-приложение (1-2 ГБ) → на сервере с 8 ГБ RAM это уже впритык, лучше закладывать 16 ГБ.
• MinIO как S3-бэкенд для приватного Docker registry — комбинация, которая часто встречается при самостоятельной сборке CI/CD. Если у вас уже развёрнут приватный Docker registry, учтите, что registry сам по себе не требователен к RAM, но пиковая нагрузка при параллельной сборке и пуше нескольких образов складывается с нагрузкой MinIO.
• MinIO рядом с Nextcloud или другим self-hosted облаком, где MinIO выступает S3-бэкендом для хранения файлов — тут разумно свериться с требованиями самого приложения, например в статье сколько RAM нужно для Nextcloud, и не забыть добавить сверху ресурсы под MinIO.

Общий принцип планирования "с запасом" для сервера в целом, а не только под конкретное приложение, разобран в статье про оперативную память с запасом.

Как проверить, что памяти реально не хватает

Не гадайте — смотрите метрики. У MinIO есть встроенный Prometheus-эндпоинт, но для быстрой диагностики достаточно системных утилит.

# Общая картина по памяти и page cache
free -h

# Расход памяти конкретно процессом MinIO
ps aux | grep minio

# Если MinIO в Docker — статистика контейнера в реальном времени
docker stats minio

# Метрики самого MinIO (нужен аутентифицированный доступ)
mc admin info local

Тревожные сигналы, что RAM пора увеличивать:

• В docker stats контейнер MinIO регулярно упирается в заданный лимит памяти.
• В логах — ошибки таймаутов при multipart upload больших файлов.
• Клиенты жалуются на возросшую задержку при чтении "горячих" объектов — признак, что page cache вытесняется раньше времени.
• dmesg показывает срабатывания OOM killer для процесса minio — это уже критично.

Если сервер работает не только под MinIO, полезно параллельно проверить общую загрузку диска — иногда то, что выглядит как нехватка памяти, на самом деле упирается в скорость самого накопителя. Как это отличить, описано в статье про медленный диск на VPS.

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