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

MAATRIX

Rclone на первый взгляд кажется прожорливым: команда синхронизирует терабайты между S3, Google Drive и локальным диском, и логично ждать, что память кончится где-то на середине переноса. На практике всё не так — rclone почти никогда не держит в памяти сами данные файлов, он их стримит. Память съедают другие вещи: количество параллельных передач, размер буферов на каждую, листинг дерева из сотен тысяч объектов и мультипарт-аплоуд в облачные бэкенды. Разберём, что конкретно грузит RAM в rclone и как посчитать свою цифру, а не гадать по объёму данных.

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

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

Главное отличие от инструментов вроде restic или borg: rclone не строит индекс с хешами блобов и не дедуплицирует содержимое. Он сравнивает списки файлов (по размеру, времени изменения или хешу) и копирует то, что отличается. Память растёт не с объёмом данных, а с количеством объектов в дереве и с тем, сколько файлов вы гоните параллельно.

Из чего складывается память: transfers, buffer-size, checkers

Три флага определяют базовое потребление RAM при обычном sync/copy, и все три — про параллелизм, а не про объём.

--transfers — сколько файлов копируется одновременно. По умолчанию 4. Каждая параллельная передача держит собственный буфер на чтение/запись.

--buffer-size — размер буфера на одну передачу, по умолчанию 16 МиБ. Это не куда пишется весь файл целиком — это скользящее окно, через которое данные читаются с одной стороны и пишутся на другую потоково, без буферизации файла целиком в памяти.

--checkers — сколько файлов одновременно сравнивается (метаданные, хеши) без передачи содержимого. По умолчанию 8. Проверки лёгкие — читают метаданные или считают хеш потоково, не держат файл в памяти.

Грубая базовая формула:

память под буферы ≈ --transfers × --buffer-size

При настройках по умолчанию это 4 × 16 МиБ = 64 МБ — совсем немного. Поднять --transfers до 16 при том же --buffer-size даёт уже 256 МБ только на буферы передачи, и это не считая листинга и оверхеда самого процесса (rclone на Go, у голого бинарника есть свой базовый расход в районе 30–60 МБ на рантайм, зависит от версии).

Проверить фактический пик для своей задачи:

/usr/bin/time -v rclone sync /data remote:bucket --transfers 8 2>&1 | grep -i "maximum resident"

Если sync падает по памяти на маленьком сервере, часто виноват не сам rclone, а слишком агрессивный параллелизм на медленном канале: буферы заполняются быстрее, чем опустошаются в сеть, растёт очередь незавершённых передач. Первым делом снижайте --transfers, а не наращивайте RAM.

Листинг файлов: память растёт с их количеством, а не размером

Прежде чем что-то копировать, rclone должен построить список файлов на источнике и на назначении, чтобы понять разницу. Именно листинг — основной источник роста памяти на больших деревьях, а не сама передача.

По умолчанию rclone обходит дерево постранично, каталог за каталогом, и держит в памяти не весь список сразу, а порции по мере обхода — это экономит RAM ценой большего числа отдельных запросов к API бэкенда. Флаг --fast-list меняет стратегию: он запрашивает листинг всего дерева за минимум вызовов API (там, где бэкенд это поддерживает — S3, Google Drive, большинство облачных провайдеров) и держит весь список в памяти целиком.

rclone sync /data remote:bucket --fast-list

Компромисс прямой: --fast-list снижает число API-запросов (важно для бэкендов с оплатой за операции) и часто ускоряет синхронизацию, но требует держать весь список объектов в оперативке. По прикидкам из практики сообщества rclone, на дерево из миллиона файлов лишний расход памяти от полного листинга — от нескольких сотен мегабайт до примерно гигабайта. Это ориентир, а не измеренная константа: зависит от длины путей и версии rclone, для своего дерева стоит замерить, а не полагаться на чужую цифру.

Практический вывод: на десятках тысяч файлов --fast-list почти всегда безопасен и выгоден. Если счёт идёт на многие миллионы объектов на сервере с 1–2 ГБ RAM — либо не используйте --fast-list, либо синхронизируйте по поддеревьям за несколько проходов вместо одного огромного.

S3, Google Drive и Backblaze: мультипарт-аплоуд и особенности бэкендов

Каждый облачный бэкенд добавляет свой слой буферизации поверх базовых --transfers/--buffer-size — при загрузке крупных файлов частями (multipart upload).

Для S3-совместимых хранилищ (Backblaze B2 через S3 API, MinIO, Wasabi, AWS S3) файлы крупнее порога --s3-upload-cutoff (около 200 МиБ по умолчанию) режутся на части размером --s3-chunk-size (5 МиБ по умолчанию) и грузятся параллельно, число одновременных частей задаёт --s3-upload-concurrency (4 по умолчанию). Итоговый расход на одну такую загрузку:

память на файл ≈ --s3-chunk-size × --s3-upload-concurrency

При дефолтах это 5 МиБ × 4 = 20 МБ на один крупный файл, и это умножается на --transfers, если параллельно грузится несколько больших файлов сразу. Подняли --s3-chunk-size до 64 МиБ ради скорости аплоуда толстых бэкапов — умножайте на concurrency и на число параллельных файлов, память растёт быстро:

rclone copy /backups remote:bucket --s3-chunk-size 64M --s3-upload-concurrency 4 --transfers 4

64 МБ × 4 × 4 = 1 ГБ только на буферы мультипарт-аплоуда — на сервере с 1 ГБ RAM такая связка флагов почти гарантированно уронит процесс по OOM.

У Google Drive свой параметр --drive-chunk-size (около 8 МиБ по умолчанию), у нативного Backblaze B2 — --b2-chunk-size, обычно крупнее из-за меньшего минимального порога для частей. Логика та же: размер части × параллелизм — добавочная память сверх буферов передачи. Прежде чем поднимать chunk-size ради скорости на медленном тарифе, проверьте, что RAM выдержит умножение.

rclone mount: отдельный профиль памяти

rclone mount — не разовая команда, а постоянный процесс, представляющий удалённое хранилище локальной файловой системой через FUSE. Профиль памяти здесь принципиально другой, чем у sync/copy.

Ключевая настройка — --vfs-cache-mode:

Кроме VFS-кэша есть --dir-cache-time (5 минут по умолчанию) — как долго держать в памяти листинг каталогов между обращениями к хранилищу. На дереве с сотнями тысяч файлов увеличение этого времени снижает число повторных запросов, но дольше держит структуру в RAM:

rclone mount remote:bucket /mnt/data \
  --vfs-cache-mode writes \
  --dir-cache-time 12h \
  --vfs-cache-max-size 10G \
  --allow-other &

--vfs-cache-max-size ограничивает именно дисковый кэш, не память процесса — но чем больше файлов активно открыто через mount, тем выше расход RAM на метаданные и хендлы. Для mount под несколько приложений с активным вводом-выводом закладывайте память отдельно от разовых sync-заданий на том же сервере — это два разных профиля нагрузки, их пики складываются вручную.

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

Несколько настроек двигают именно RAM, а не общую скорость синхронизации:

Снизить --transfers и --checkers. Первое, что стоит попробовать на маленьком сервере — не апгрейд тарифа:

rclone sync /data remote:bucket --transfers 2 --checkers 4

Не включать --fast-list на очень больших деревьях с малым запасом RAM. Чуть больше API-запросов — приемлемая плата за то, что процесс не упадёт на середине листинга.

Использовать --size-only вместо хеш-сравнения там, где это оправдано. Сравнение по размеру и времени изменения дешевле, чем пересчёт хешей на каждый файл — заметно на слабом тарифе при большом дереве.

GOGC для более агрессивной сборки мусора. Rclone написан на Go — тот же приём, что и для restic:

GOGC=50 rclone sync /data remote:bucket --transfers 4

По умолчанию GOGC=100: сборщик срабатывает, когда куча выросла вдвое с прошлого прохода; GOGC=50 снижает пиковую память ценой более частых пауз — для ночного sync цена почти не заметна.

Разносить mount и разовые sync-задания по разным окнам или серверам, если оба тяжёлые — иначе их пики памяти суммируются в непредсказуемый момент.

Что касается сервера — под разовые cron-синхронизации небольших и средних деревьев (до нескольких сотен тысяч файлов) достаточно 1 vCPU, 1–2 ГБ RAM: настройки по умолчанию укладываются с запасом, --fast-list можно включать без риска. Для миллионов объектов, повышенного --transfers при переносах между облаками и/или постоянно работающего rclone mount для нескольких приложений разумно сразу брать 2–4 vCPU, 4 ГБ RAM. Диск важен не меньше памяти: VFS-кэш и буферы mount в режиме full быстро съедают место на большом хранилище — посчитайте заранее, сколько дискового пространства закладывать с запасом.

Если rclone у вас — часть общей схемы бэкапов, посмотрите также требования соседних инструментов: сколько RAM нужно для restic — там похожая логика «данные почти не грузят память, зато метаданные растут с числом файлов», и подборку конфигураций под весь стек — сколько ресурсов нужно VPS для бэкапов и архива. Регулярные синхронизации удобно запускать через cron — как настроить, разобрано в статье про cron-задачи на VPS.

Сервер под rclone на MAATRIX разворачивается за несколько минут, конфигурацию подбираем под размер дерева и число параллельных передач. Оплата — картами российских банков, по СБП, криптовалютой или токеном MAAT, без иностранной карты даже для локаций в США и Великобритании.

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