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

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

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

<code xml>
<options>
    <maxFolderConcurrency>1</maxFolderConcurrency>
    <progressUpdateIntervalS>-1</progressUpdateIntervalS>
    <maxConcurrentIncomingRequestKiB>32768</maxConcurrentIncomingRequestKiB>
</options>
</code>

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

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

<code xml>
<folder id="..." path="...">
    <hashers>1</hashers>
    <copiers>1</copiers>
    <pullerMaxPendingKiB>16384</pullerMaxPendingKiB>
    <scanProgressIntervalS>-1</scanProgressIntervalS>
</folder>
</code>

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

^ Параметр ^ Почему не трогать ^
| 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-дерева.