meta data for this page
  •  

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

wiki:sync:syncthing:low_performance_tuning [2026/08/06 08:19] – created mchuswiki:sync:syncthing:low_performance_tuning [2026/08/07 05:45] (current) – mchus
Line 33: Line 33:
 </code> </code>
  
-===== Параметры, которые не снижать =====+===== Параметры, которые не снижать (общий случай) =====
  
 ^ Параметр ^ Почему не трогать ^ ^ Параметр ^ Почему не трогать ^
-| fsWatcherEnabled | Официальная рекомендация — включать, а не выключать. Live-нотификации дешевле по ресурсам, чем полное периодическое пересканирование дерева. | 
 | numConnections (на устройство) | Прямой trade-off с throughput. Если устройство — основной партнёр по передаче больших объёмов, снижение до 1 ощутимо замедляет передачу. Значение выше дефолта на конкретном устройстве обычно выставлено намеренно. | | 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-дерева.