Table of Contents

Тюнинг Syncthing на слабом железе

Глобальные опции

Параметр Дефолт Значение для слабого железа Причина
maxFolderConcurrency 0 (все папки разом) 1 не хэшировать несколько папок параллельно — источник пиковой памяти
progressUpdateIntervalS 5 -1 не тратить память/CPU на прогресс передачи
maxConcurrentIncomingRequestKiB 0 (unlimited) 32768 ограничить буфер входящих запросов 
<options>
    <maxFolderConcurrency>1</maxFolderConcurrency>
    <progressUpdateIntervalS>-1</progressUpdateIntervalS>
    <maxConcurrentIncomingRequestKiB>32768</maxConcurrentIncomingRequestKiB>
</options>

Настройки на уровне папки

Параметр Дефолт Значение для слабого железа Причина
hashers 0 (auto = число ядер) 1 меньше пиковой памяти при хэшировании крупных файлов
copiers 0 1 то же для копирования при синхронизации
pullerMaxPendingKiB 0 (unlimited) 16384 ограничить буфер на pull
scanProgressIntervalS 0 -1 не тратить память/CPU на прогресс сканирования 
<folder id="..." path="...">
    <hashers>1</hashers>
    <copiers>1</copiers>
    <pullerMaxPendingKiB>16384</pullerMaxPendingKiB>
    <scanProgressIntervalS>-1</scanProgressIntervalS>
</folder>

Параметры, которые не снижать (общий случай)

Параметр Почему не трогать
numConnections (на устройство) Прямой trade-off с throughput. Если устройство — основной партнёр по передаче больших объёмов, снижение до 1 ощутимо замедляет передачу. Значение выше дефолта на конкретном устройстве обычно выставлено намеренно.

fsWatcher на BSD: отдельный случай

Официальная рекомендация Syncthing — держать `fsWatcherEnabled` включённым (live-нотификации дешевле, чем полное периодическое пересканирование). Это верно для Linux (inotify — одна рекурсивная подписка на дерево) и для папок с разумным числом файлов.

На FreeBSD/BSD `fsWatcher` реализован через kqueue, который не поддерживает рекурсивное наблюдение — библиотека (`github.com/syncthing/notify`) вынуждена открывать отдельный watch (и держать отдельный vnode) на каждую директорию дерева. Для папки с сотнями тысяч мелких вложенных директорий (типичная раскладка `receive-encrypted` — блоки хранятся как хэш-шардированное дерево) это означает сопоставимое число живых vnode и watch-дескрипторов, что на системе с ограниченным `kern.maxvnodes` может спровоцировать агрессивный vnode-реклейм — блокирующий, системный, а не только для процесса Syncthing.

Диагностический признак: в heap-профиле процесса (support bundle → `.pprof`, смотреть через `go tool pprof`) большая доля памяти уходит на `github.com/syncthing/notify.*` (`node.addchild`, `kq.Record`, `watchpoint.Add`) вместо полезных данных синхронизации.

Условие Рекомендация
Linux, любой размер папки `fsWatcherEnabled=true` — штатная рекомендация верна
BSD/kqueue, папка с умеренным числом файлов `fsWatcherEnabled=true` — штатная рекомендация верна
BSD/kqueue, папка с сотнями тысяч файлов/директорий (в т.ч. `receive-encrypted`), особенно receive-only (локальных изменений на этом хосте не бывает — их и незачем ловить fsWatcher'ом) `fsWatcherEnabled=false` + разумный `rescanIntervalS` вместо live-наблюдения

Для sendreceive-папки с реальными локальными изменениями (например, что-то пишет в неё сторонний процесс напрямую по SMB) — `rescanIntervalS` подобрать под частоту появления этих изменений, а не под дефолт: если новые файлы предсказуемо приходят раз в сутки, суточный рескан ловит их с разумной задержкой без постоянно открытого watch-дерева.