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

MAATRIX

SeaweedFS придумали специально для задачи, на которой захлёбываются обычные файловые системы и даже классический MinIO: миллиарды мелких файлов. Идея в том, что накладные расходы на файл — размер inode, метаданные, индекс — должны быть минимальными, а не расти линейно с числом объектов до тех пор, пока не съедят всю память сервера. Но именно поэтому вопрос "сколько RAM нужно" здесь не сводится к одной цифре: у SeaweedFS четыре разных компонента (master, volume server, filer, S3 gateway), и у каждого свой профиль потребления памяти, зависящий от конкретных настроек. Разберём по частям, где что расходуется и как посчитать под свою нагрузку.

Архитектура SeaweedFS: четыре компонента, четыре профиля памяти

В отличие от MinIO, где обычно один и тот же процесс отвечает за всё, SeaweedFS разделён на роли, и это разделение — ключ к пониманию расхода RAM.

• Master — держит топологию кластера: какие volume server существуют, сколько на них volume'ов (томов с данными), сколько в каждом свободного места. Master не хранит метаданные отдельных файлов — это принципиальное архитектурное решение, которое и делает SeaweedFS лёгким на больших объёмах.
• Volume server — хранит сами данные ("needles" — мелкие блоки данных внутри больших файлов-томов, по умолчанию до 30 ГБ на том) и индекс needle map, который сопоставляет ID файла его смещению внутри тома. Это самый интересный с точки зрения RAM компонент.
• Filer — надстройка, которая даёт POSIX-подобное дерево каталогов и путей вместо плоского набора ID. Filer хранит метаданные (имена файлов, права, структуру папок) во внешней базе — выбор базы напрямую определяет расход RAM.
• S3 API gateway (weed s3) — прослойка, которая транслирует S3-запросы в вызовы filer. Сама по себе легковесная, память тратит в основном на буферы активных запросов, похоже на то, как это устроено в MinIO.

Все четыре роли можно запускать на одном сервере для теста или развести по разным машинам в продакшене — расход памяти считается для каждой роли отдельно и суммируется, если они живут на одном хосте.

Master server: минимальный, но растущий с числом volume'ов

Master — самый лёгкий компонент по памяти, потому что он оперирует не файлами, а томами. Один том вмещает десятки или сотни тысяч мелких файлов, и master хранит информацию именно о томе (его расположение, объём, статус репликации), а не о каждом файле внутри.

На практике это означает, что даже кластер с сотнями миллионов файлов, но разумным числом томов (сотни-тысячи), держит master в границах:

• 256-512 МБ RAM — для небольшого кластера с несколькими volume server и десятками-сотнями томов.
• 1-2 ГБ RAM — для кластера покрупнее, с тысячами томов, активной репликацией между дата-центрами и включённым мониторингом через встроенный веб-интерфейс.

Запустить master для теста просто:

weed master -mdir=/opt/seaweedfs/master -port=9333

Важный нюанс: если вы держите несколько master в режиме HA (Raft-консенсус между 3 и более узлами), каждый узел считается по тем же формулам — общая память кластера не складывается в одну "виртуальную" сумму, просто каждый master должен пережить те же тысячи томов независимо.

Filer: метаданные каталогов зависят от выбранной базы

Filer — единственный компонент SeaweedFS, чей расход RAM определяется не самим SeaweedFS, а базой данных, которую вы выбрали под его метаданные. Это одновременно и гибкость, и источник путаницы: цифры для одной и той же нагрузки будут совсем разными в зависимости от бэкенда.

• LevelDB (локальная, по умолчанию для одиночного filer) — не требует отдельного сервиса, метаданные лежат на диске рядом с filer. Сам процесс filer держится в границах 200-500 МБ RAM даже при значительном дереве каталогов, но такой вариант не годится для нескольких filer-узлов одновременно — LevelDB не рассчитана на конкурентный доступ с разных серверов.
• PostgreSQL или MySQL — стандартный выбор для продакшена с несколькими filer или высокой доступностью. Расход памяти filer при этом минимален (те же 200-500 МБ), но нужно закладывать RAM отдельно под саму СУБД — как под любую реляционную базу под нагрузкой.
• Redis — быстрый вариант, но держит весь объём метаданных в памяти целиком, что при десятках миллионов файлов и длинных путях может ощутимо вырасти — считайте отдельно как под обычный инстанс Redis под свой объём.
• Cassandra, etcd — для по-настоящему больших геораспределённых инсталляций, где выбор бэкенда — уже отдельный архитектурный разговор, а не просто вопрос RAM.

Для среднего проекта самый предсказуемый по памяти вариант — PostgreSQL: сам filer остаётся лёгким, а требования к БД считаются и масштабируются по её собственным правилам, независимо от роста количества файлов в SeaweedFS.

Практические конфигурации по сценариям

Собирая всё вместе — если разворачивать все роли на одном сервере (типичный старт для проекта, который ещё не дорос до распределённого кластера):

Если сервер планируется не только под SeaweedFS, а ещё и под соседние сервисы (веб-приложение, БД для другой задачи), не забудьте о принципе "считать пиковую сумму, а не минимумы" — он подробно разобран в статье про оперативную память с запасом. Под сам объём данных (не RAM, а диск) стоит закладывать запас по тем же соображениям, что и для любого файлового хранилища — см. статью про дисковое пространство с запасом.

Docker Compose и мониторинг памяти на практике

Для тестового или небольшого продакшен-развёртывания удобнее поднять все роли через Docker Compose, сразу выставив лимиты памяти на каждый контейнер:

services:
  master:
    image: chrislusf/seaweedfs:latest
    command: "master -mdir=/data -port=9333"
    volumes:
      - master-data:/data
    ports:
      - "9333:9333"
    deploy:
      resources:
        limits:
          memory: 1G
    restart: unless-stopped

  volume:
    image: chrislusf/seaweedfs:latest
    command: "volume -dir=/data -max=100 -mserver=master:9333 -port=8080 -index=leveldb"
    volumes:
      - volume-data:/data
    ports:
      - "8080:8080"
    deploy:
      resources:
        limits:
          memory: 4G
    depends_on:
      - master
    restart: unless-stopped

  filer:
    image: chrislusf/seaweedfs:latest
    command: "filer -master=master:9333 -port=8888"
    volumes:
      - filer-data:/data
    ports:
      - "8888:8888"
      - "8333:8333"
    deploy:
      resources:
        limits:
          memory: 512M
    depends_on:
      - volume
    restart: unless-stopped

volumes:
  master-data:
  volume-data:
  filer-data:

Здесь сознательно выбран -index=leveldb для volume server — это разумный дефолт, если вы не уверены, что число файлов на узел останется небольшим: лучше заранее заложить экономию RAM, чем потом мигрировать индекс под нагрузкой.

Проверка реального расхода по компонентам:

# Память по каждому контейнеру отдельно
docker stats master volume filer

# Общая картина по серверу, включая page cache
free -h

# Метрики SeaweedFS в формате Prometheus (у master и volume server есть свои эндпоинты)
curl -s http://localhost:9333/metrics | grep memory

Общий принцип лимитов для контейнеров — не только для SeaweedFS — разобран в статье про лимиты CPU и памяти в Docker: не пережимайте volume server слишком туго, иначе даже leveldb-индекс начнёт упираться в отсутствие места под свой собственный кеш операций записи. Если при этом растёт iowait, а не расход RAM, дело может быть не в памяти, а в диске — как это отличить, показано в статье про медленный диск на VPS.

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