Загрузка файлов на Samba-сервер с HDD идёт в два раза медленнее скачивания, а NFS быстрее: параметр strict sync

Виртуальные машины и серверы
1

Что было. Файловый сервер на Debian 12 с общими папками Samba на жёстких дисках. Скачивание 112 МБ/с (гигабитная сеть), загрузка с клиентов Windows около 40 МБ/с. По NFS и SCP на тот же сервер 90 МБ/с; шары на SSD дают полную скорость в обе стороны. Процессор свободен, диск загружен на те же 40 МБ/с.

Причина. Начиная с Samba 4.x параметр strict sync по умолчанию yes: сервер честно выполняет fsync по каждому запросу клиента на сброс буферов, а клиенты Windows шлют такие запросы часто. На SSD это незаметно, на HDD каждый fsync это ожидание позиционирования головок. Автор добавил в smb.conf одну строку и получил ~90 МБ/с; прочие «оптимизации» (socket options, aio, размеры буферов) эффекта не дали. Подтверждено.

Настройка.

[global]
   strict sync = no

testparm, затем smbcontrol all reload-config. Компромисс: при внезапном отключении питания последние секунды записи могут не дойти до диска, хотя клиент считал их записанными. На сервере с резервным питанием и на виртуальной машине с надёжным хранилищем риск невелик; для критичных данных оставить yes и переносить шару на SSD.

Что ещё влияет на скорость Samba, по убыванию.

  1. Носитель и файловая система назначения: HDD с мелкими файлами медленны при любом протоколе; ext4 с noatime.
  2. Версия протокола: server min protocol = SMB3 (без SMB1) и на клиенте SMB3 с многоканальностью при нескольких адаптерах (server multi channel support = yes).
  3. Подпись и шифрование: server signing = mandatory и smb encrypt = required добавляют нагрузку на процессор; на одном ядре виртуальной машины могут стать потолком.
  4. Антивирус на клиенте Windows сканирует сетевые записи; на сервере сканер файлов (vfs objects с антивирусными модулями) удваивает время.
  5. aio read size/aio write size по умолчанию включены и уже помогают; ручные socket options в современных ядрах чаще вредят.

Как измерять. Один большой файл (dd if=/dev/urandom of=test bs=1M count=2048) в обе стороны через шару и через scp: если scp быстрее Samba на записи, дело в настройках Samba, а не в сети или диске. iostat -x 1 на сервере во время копирования: высокий w_await при низкой пропускной способности признак частых fsync.

Параметр описан в документации Samba.