Сколько RAM нужно для File Browser

MAATRIX

Вы ищете, сколько памяти закладывать под File Browser — веб-интерфейс для управления файлами на сервере, — и большинство ответов в сети либо расплывчаты, либо взяты из документации другого проекта. File Browser — один из самых лёгких self-hosted инструментов, который вы когда-либо разворачивали, но у него есть свои особенности потребления памяти, которые стоит понимать до того, как вы закажете сервер. Разберём, куда уходит RAM, что её реально нагружает и какую конфигурацию брать под разные сценарии.

Что вообще такое File Browser и зачем ему память

File Browser (filebrowser/filebrowser на GitHub) — это единственный статически собранный Go-бинарник со встроенным веб-интерфейсом: загрузка, скачивание, редактирование текстовых файлов, переименование, шаринг по ссылке, простая система пользователей и прав. Никакого PHP, никакого Node.js рантайма, никакой отдельной СУБД по умолчанию — состояние хранится в файле filebrowser.db на базе BoltDB (embedded key-value хранилище, живёт в том же процессе).

Именно поэтому потребление памяти у File Browser принципиально другое, чем у Nextcloud или PhotoPrism: нет отдельного процесса PHP-FPM, нет MySQL/PostgreSQL, нет очередей на переиндексацию. Всё — один процесс, и вся память, которую он берёт, тратится на:

• сам рантайм Go (сборщик мусора, горутины на каждое HTTP-соединение);
• кеш метаданных файловой системы (список файлов, их размеры, права);
• буферы на активные операции — генерацию превью изображений, загрузку/скачивание больших файлов;
• сессии пользователей и токены авторизации.

В состоянии простоя (никто не подключён, файлы не листаются) процесс File Browser занимает около 15-30 МБ резидентной памяти (RSS) — это близко к минимуму для программы на Go с HTTP-сервером и встроенной БД. Дальше цифра растёт, но не линейно и не драматично.

Базовое потребление в простое

Проверить это можно за минуту на любом сервере с Docker. Разворачиваем File Browser в docker-compose:

services:
  filebrowser:
    image: filebrowser/filebrowser:latest
    container_name: filebrowser
    restart: unless-stopped
    ports:
      - "8080:80"
    volumes:
      - /srv/files:/srv
      - ./filebrowser.db:/database.db
      - ./filebrowser.json:/.filebrowser.json

Файл filebrowser.json минимально нужен, чтобы задать путь к базе явно:

{
  "port": 80,
  "baseURL": "",
  "address": "",
  "log": "stdout",
  "database": "/database.db",
  "root": "/srv"
}

После docker compose up -d смотрим потребление:

docker stats filebrowser --no-stream

На тестовой каталоге из пары тысяч файлов процесс в простое стабильно держится в районе 20-35 МБ RSS. Это ориентир по личным наблюдениям на нескольких инсталляциях — у вас цифра может отличаться на десяток мегабайт в зависимости от версии, количества файлов и активности других пользователей, но порядок величины будет тем же.

Для сравнения — типичные соседи по функции памяти на VPS:

File Browser в этом ряду — один из самых экономных вариантов, если задача именно "простой веб-интерфейс к файлам на диске", а не полноценная синхронизация с версионированием и мобильными клиентами, как у Nextcloud.

Что реально поднимает потребление памяти

Три фактора двигают цифру вверх, и их стоит понимать заранее, а не гадать постфактум.

1. Число файлов и глубина индексации. File Browser не хранит полный поисковый индекс в памяти постоянно, но при обходе директории (листинг папки, поиск) он читает метаданные всех файлов в текущей директории и кеширует их на время сессии. На директориях с десятками тысяч файлов в одной папке (не вложенных, а именно "плоских") пиковое потребление при листинге может подскочить до 100-150 МБ на время операции, а затем осесть обратно после сборки мусора Go. Если у вас архив с сотнями тысяч мелких файлов в одной плоской структуре — тестируйте на копии данных, прежде чем закладывать RAM.

2. Генерация миниатюр (thumbnails). Если включена опция превью для изображений в filebrowser.json ("branding" не влияет, а вот генерация превью через встроенный обработчик — да), каждая генерация thumbnail для большого изображения (RAW, TIFF, фото 40+ Мпикс) временно съедает память под декодирование изображения в буфер. Один запрос — обычно 10-50 МБ на время обработки, но если несколько пользователей одновременно листают папку с фотографиями и триггерят массовую генерацию превью — пики могут наложиться друг на друга. На слабом сервере (512 МБ) это способно вызвать OOM при параллельной нагрузке нескольких клиентов.

3. Одновременные загрузки/скачивания больших файлов. File Browser стримит файлы, а не грузит их целиком в память в норме — но при multipart-загрузке через веб-форму часть данных проходит через буферы Go до записи на диск. При одной операции это некритично, но 5-10 параллельных загрузок по гигабайту каждая на слабом сервере с ограниченным RAM и медленным диском могут создать очередь и рост потребления, пока данные не будут сброшены на диск.

Сколько закладывать: таблица по сценариям

Дальше — не измеренные бенчмарки, а ориентир из практики эксплуатации подобных лёгких Go-сервисов на VPS; у вас цифры сдвинутся в зависимости от нагрузки и файловой структуры.

Если File Browser — единственный сервис на сервере и файлы у вас не в диких масштабах (до сотни тысяч), 1 ГБ RAM с запасом покрывает практически любой сценарий малой команды. 512 МБ формально хватает, но без запаса на скачки при параллельных операциях — на минимальном тарифе лучше сразу брать план с 1 ГБ, разница в цене обычно небольшая, а нервов сэкономит.

Практическая настройка под ограниченную память

Если сервер действительно тесный (например, старый VPS на 512 МБ, который жалко списывать), несколько вещей снижают пиковое потребление:

Отключите генерацию превью там, где она не нужна — в filebrowser.json:

{
  "port": 80,
  "database": "/database.db",
  "root": "/srv",
  "commands": {}
}

Превью управляются на уровне пользовательских настроек в интерфейсе (Settings → Global Settings), выключите "Preview" для типов файлов, которые вам не критичны для просмотра миниатюрами — это уберёт декодирование изображений из горячего пути.

Ограничьте контейнер по памяти явно, чтобы получить честный OOM с перезапуском вместо зависания сервера целиком:

services:
  filebrowser:
    image: filebrowser/filebrowser:latest
    restart: unless-stopped
    deploy:
      resources:
        limits:
          memory: 384M
    ports:
      - "8080:80"
    volumes:
      - /srv/files:/srv
      - ./filebrowser.db:/database.db
      - ./filebrowser.json:/.filebrowser.json

Обратите внимание: секция deploy.resources в чистом docker compose (не Swarm) применяется начиная с Docker Compose v2 — если у вас старая версия, используйте вместо неё mem_limit: 384m напрямую в сервисе.

Добавьте swap, если сервер балансирует на грани — это не решит проблему нехватки RAM под нагрузкой, но даст системе шанс пережить кратковременный пик вместо мгновенного OOM-килла. Как это сделать по шагам, разобрано в статье про настройку swap на Ubuntu 24.04 — процесс идентичен для любого дистрибутива, меняются только имена пакетов.

Не держите File Browser за тяжёлым reverse proxy с избыточным логированием — подробный access-лог на каждый чанк загрузки добавляет накладные расходы на I/O и память под буферизацию. Сравнение подходов — в статье Caddy или Nginx — что выбрать для сервера.

File Browser vs альтернативы — когда он оправдан, а когда нет

File Browser — не универсальный ответ на "нужен веб-доступ к файлам". Он отлично закрывает конкретную нишу: простой, быстрый, лёгкий веб-интерфейс без синхронизации, версионирования файлов и мобильных приложений. Если ваша задача шире, смотрите в сторону соседей:

• Нужна синхронизация между устройствами, версионирование, календари/контакты — это Nextcloud, но он тяжелее на порядок и требует MySQL/PostgreSQL плюс минимум 1-2 ГБ RAM для комфортной работы.
• Нужна P2P-синхронизация папок между машинами без центрального сервера-хранилища — это Syncthing, другая модель работы, файлы реплицируются, а не хранятся централизованно.
• Нужен объектный S3-совместимый доступ для приложений, а не человека через браузер — это MinIO, у него другой протокол доступа и другая модель авторизации, память тоже сопоставима с File Browser в простое.
• Нужен полноценный файловый шлюз с SFTP/FTP/WebDAV поверх облачных бэкендов — присмотритесь к SFTPGo, он тяжелее по конфигурации, но гибче по протоколам.

File Browser выигрывает там, где важна простота развёртывания за 5 минут и минимальный footprint — временный доступ подрядчику к папке с макетами, личный файловый шлюз для бэкапов, замена FTP для команды из 3-5 человек.

Мониторинг реального потребления на вашем сервере

Не верьте таблицам выше на слово — измерьте у себя. Три команды покажут реальную картину:

# Мгновенный снимок потребления контейнера
docker stats filebrowser --no-stream

# Потребление процесса на хосте (если запущен не в Docker)
ps aux | grep filebrowser

# История потребления за период (нужен docker stats в watch-режиме или сторонний мониторинг)
watch -n 5 'docker stats filebrowser --no-stream'

Если хотите видеть график потребления во времени, а не разовые снимки — разверните лёгкий мониторинг из коробки, это займёт минут 15-20 и сразу покажет реальные пики при пользовательской нагрузке. Подробный разбор — в статье про мониторинг на Ubuntu 24.04 с нуля (подход аналогичен для Ubuntu и Debian, различаются только команды установки пакетов).

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