NFS в Linux: v3 и v4.1, async, rsize/wsize и mount options для максимального throughput

NFS остаётся одним из самых простых способов быстро вынести каталоги за пределы сервера: шарим /srv/data с одного узла и монтируем на десятки других. Но «просто работает» часто превращается в «почему медленно?» или «почему подвисло после сетевого глитча?». Ниже — практический разбор самых частых точек настройки: выбор NFS v3 vs v4.1, влияние async на сервере, параметры rsize/wsize и ключевые mount options, которые сильнее всего влияют на throughput, задержки и предсказуемость.

Базовая модель NFS: где теряется производительность

Производительность NFS почти всегда упирается не в «скорость диска» как таковую, а в сочетание факторов:

• Сеть: RTT, потери, перегрузка, MTU и поведение TCP.
• Размер операций: rsize/wsize, паттерн I/O (много мелких файлов vs большие последовательные чтения/записи).
• Семантика надёжности: sync/async на сервере, fsync в приложениях, требования к консистентности.
• Locking: блокировки файлов и их восстановление после обрывов.
• Конкуренция: сколько клиентов и сколько RPC одновременно «в полёте» на один экспорт и один mount.

Практический вывод: «подкрутить один параметр» обычно недостаточно. Нужен минимальный набор правильных решений по протоколу, размерам операций и политике записи, а затем — измерения на вашей нагрузке.

NFS v3 и v4.1: что выбирать и почему

Ключевые отличия v3

NFSv3 исторически прост и широко совместим, но опирается на отдельные механизмы вокруг протокола:

• Отдельный сервис для locking (NLM) и сопутствующие компоненты — больше движущихся частей.
• Часто использует несколько RPC-сервисов, что осложняет жизнь за NAT/фаерволами из-за портмаппинга и «плавающих» портов.
• На проблемной сети и при реконнектах чаще всплывают «странные» таймауты и зависания, которые внешне выглядят как «NFS тормозит».

Ключевые отличия v4.1

NFSv4.x — это уже другой NFS: stateful-модель, встроенные блокировки, более предсказуемое восстановление состояния. В контексте v4.1 обычно важны такие моменты:

• Сессии и состояние: проще переживать краткие сетевые проблемы без разрушения модели блокировок.
• Locking встроен в протокол: меньше внешних зависимостей для блокировок.
• Как правило, проще с межсетевыми экранами: меньше «расползания» по портам.
• Масштабирование и параллелизм обычно проще, но чудес не будет: упираться всё равно будете в сеть/диск/CPU и паттерн I/O.

Если нет жёсткой необходимости в совместимости со старым окружением, для новых внедрений чаще выбирают NFSv4.1: проще с блокировками, проще с фаерволами и обычно меньше сюрпризов при реконнектах.

Когда v3 всё ещё оправдан

v3 может быть оправдан, если:

• есть легаси-клиенты/устройства, которые v4.x не умеют или умеют нестабильно;
• сценарий очень простой (например, «read-mostly»), а сеть и жизненный цикл клиентов полностью под контролем;
• требуется поведение/инструменты, завязанные именно на v3 (в старых кластерах такое встречается).

Если вы используете NFS под веб-нагрузку (например, общие каталоги для сессий/кэша), отдельно посмотрите на типовые грабли и практики из статьи про хранение PHP-сессий и кэша: часто проблема «NFS медленный» на самом деле про блокировки и мелкие метаданные.

Locking: почему он ломает «производительность» и «надёжность»

Файловые блокировки в NFS — не декоративная функция. Многие приложения опираются на advisory locks: БД, очереди, PHP-сессии в файлах, некоторые CMS, офисные документы, компиляторы. Ошибки в locking обычно выглядят так:

• процессы «висят» на операции с файлом (ожидание lock);
• после краткого сетевого обрыва клиент получает ошибки доступа или бесконечные повторы;
• в приложениях появляются спорадические рассинхронизации «как будто блокировок не было».

В NFSv3 блокировки — отдельный мир с NLM. В NFSv4.x locking встроен, но появляется «состояние» и требования к корректному восстановлению сессий. На практике именно при нестабильной сети и агрессивных таймаутах проблемы с locking чаще всего маскируются под «NFS лагает».

Практические правила для locking

• Не отключайте блокировки без понимания последствий. Опции вида nolock почти всегда костыль для очень специфичных случаев.
• Если приложение использует файловые блокировки (или вы не уверены) — тестируйте реконнекты: краткое отключение интерфейса, рестарт NFS-сервера, перезапуск клиента.
• Закладывайте наблюдаемость: метрики RPC/NFS, логи kernel NFS client/server, алерты на зависшие процессы и рост ретраев.

Облачный VDS-сервер в России

Аренда виртуальных серверов с моментальным развертыванием инфраструктуры от 195₽ / мес

Подробнее

async на NFS-сервере: максимальный throughput vs риск потери данных

Опция async на стороне NFS-сервера — одна из самых «вкусных» для производительности: сервер может отвечать клиенту «записано» до того, как данные устойчиво попадут на диск. Это заметно повышает throughput на записи, особенно при большом количестве мелких операций и при нагрузке, где клиенты часто ждут подтверждений.

Цена — риск. При аварийной перезагрузке или потере питания сервера вы можете потерять подтверждённые клиенту данные или получить повреждения на уровне приложения, которое рассчитывало на строгое поведение.

async — это не «быстрее бесплатно», а осознанный обмен надёжности на скорость. Если вы не готовы формально принять риск потери данных, начинайте с sync и оптимизируйте сеть, параллелизм и размеры операций.

Когда async обычно уместен

• read-mostly шаринг (репозитории, статика) и редкие записи, где потеря последних секунд изменений допустима;
• временные данные: кэши, артефакты CI, промежуточные результаты;
• сценарии, где целостность обеспечивается на другом уровне (повторяемые вычисления, идемпотентные операции).

Когда async опасен

• БД и любые хранилища с собственным WAL/журналированием, которым важно корректное fsync.
• Файловые очереди/локи, где порядок и надёжность критичны.
• Сценарии «одна запись = деньги»: биллинг, документы, транзакции.

rsize/wsize: как они влияют на throughput и задержки

rsize и wsize — размеры блоков чтения и записи, которыми NFS-клиент обменивается с сервером. В общем виде:

• чем больше rsize/wsize, тем меньше RPC-вызовов на тот же объём данных;
• меньше RPC — обычно выше шанс выжать сетевой канал и снизить CPU overhead;
• но слишком большие значения быстрее проявляют проблемы сети (потери, фрагментация, некорректный MTU), а также могут ухудшить tail latency при потерях (повторяется крупный блок).

С чего начинать подбор

Разумная тактика: начать с адекватных дефолтов вашего дистрибутива, затем измерять реальный throughput на вашем паттерне. Часто рабочие значения лежат в диапазоне 64K–1M, но выбор зависит от RTT, качества сети, MTU, параллелизма и типа данных.

Как проверить, что rsize/wsize реально применились

В Linux проще всего смотреть текущие параметры монтирования через findmnt и nfsstat:

findmnt -t nfs,nfs4 -o TARGET,SOURCE,FSTYPE,OPTIONS
nfsstat -m

Ищите в опциях фактические rsize и wsize, а не только те, что вы указали. Ядро может «договориться» на другое значение из-за ограничений клиента/сервера или конкретной реализации.

Mount options: что чаще всего даёт прирост и где ловушки

Ниже — самые практичные mount options, которые чаще всего влияют на скорость и поведение NFS на Linux. Не воспринимайте их как универсальный пресет: важно понимать, что оптимизируете — пропускную способность, задержку, поведение при сбое или консистентность.

hard vs soft и таймауты

hard заставляет клиент бесконечно ретраить операции при проблемах с сервером или сетью. Для важных данных это чаще правильнее, но визуально выглядит как «всё зависло».

soft позволяет вернуть ошибку приложению после определённого числа повторов. Это бывает полезно для неважных данных, но легко приводит к повреждениям на уровне приложения, которое не ожидает EIO в середине записи.

С таймаутами timeo и ретраями retrans логика такая: слишком агрессивные значения на «иногда лагающей» сети могут устроить шторм повторов, а слишком большие увеличат время «подвисания» при реальной аварии. Подбирать стоит под вашу сеть и требования к времени восстановления.

proto=tcp и nconnect

TCP для NFS в современных сетях — стандартный выбор. Дальше интереснее: опция nconnect (если поддерживается ядром/дистрибутивом) открывает несколько TCP-соединений на один mount. Это может заметно поднять throughput на быстрых линках и при высокой конкуренции потоков, потому что уменьшается эффект «одного узкого горлышка» на соединение.

Но увеличение nconnect повышает нагрузку на сервер (CPU, контекстные переключения) и может ухудшить ситуацию, если bottleneck — диск, лимиты IOPS или один поток приложения.

noatime/relatime: не про NFS, но влияет на записи

Если нагрузка чувствительна к лишним метаданным, обновление atime добавляет записи. На клиентах часто уместно использовать noatime (или хотя бы relatime), если вы уверены, что приложения не зависят от точного atime.

actimeo и кэш атрибутов: баланс консистентности и скорости

NFS-клиент кэширует атрибуты (размер, mtime, права) и данные. Опция actimeo влияет на время жизни кэша атрибутов. Увеличение кэша ускоряет сценарии с большим количеством stat() (например, много мелких файлов), но повышает риск видеть «устаревшее» состояние при совместной работе множества клиентов.

Если шаринг используется как «общая рабочая директория», где разные узлы постоянно меняют одни и те же файлы, агрессивное кэширование метаданных приводит к странным эффектам. Для сценариев «один пишет, остальные читают после деплоя» — наоборот, может быть выгодно.

Если сомневаетесь, подходит ли NFS для вашего сценария или проще жить с другим транспортом, сравните поведение и ограничения в статье NFS vs SSHFS для хранения.

Серверная сторона: экспорт, sync/async и дисциплина записи

На сервере, кроме выбора sync/async, часто определяют итоговую скорость и стабильность:

• файловая система и её параметры (журналирование, барьеры, политика writeback);
• достаточный page cache и настройки writeback, иначе получите всплески latency на сбросах;
• сеть/драйверы/IRQ: сервер должен «вывозить» RPC по CPU и прерываниям.

При симптомах «всё медленно» сначала проверьте, не упирается ли сервер в одно ядро (обработка IRQ), не забит ли линк и нет ли ретраев. Иногда прирост даёт не тюнинг NFS, а грамотное распределение IRQ и нормальная сетевая дисциплина.

Надежные SSL-сертификаты

Мы предлагаем широкий спектр SSL-сертификатов от GlobalSign по самым низким ценам. Поможем с покупкой и установкой SSL бесплатно!

Подробнее

Минимальные рабочие примеры монтирования (v3 и v4.1)

Ниже — примеры для ориентира, чтобы было от чего оттолкнуться. Точные опции зависят от задачи и версии ядра.

NFSv4.1: пример с явным proto и rsize/wsize

mkdir -p /mnt/nfs
mount -t nfs4 -o vers=4.1,proto=tcp,rsize=1048576,wsize=1048576,hard,timeo=600,retrans=2 server:/export/data /mnt/nfs

NFSv3: пример с явным vers и размерами

mkdir -p /mnt/nfs
mount -t nfs -o vers=3,proto=tcp,rsize=262144,wsize=262144,hard,timeo=600,retrans=2 server:/export/data /mnt/nfs

Даже если вы задали rsize/wsize, перепроверьте фактические значения после монтирования: клиент и сервер могут согласовать меньше.

Как тестировать throughput правильно (и не обмануть себя)

Тесты NFS легко врут, если вы случайно тестируете page cache клиента или сервера. Несколько практических рекомендаций:

• Для чтения делайте минимум два прогона: «холодный» и «тёплый». Во втором вы можете читать из кэша, а не по сети.
• Для записи разделяйте «принято в кэш» и «устойчиво на диске». Если тест не делает fsync, вы фактически меряете буферизацию.
• Тестируйте вашим паттерном: большие файлы (бэкапы, медиа) и мелочь (репозитории, node_modules, vendor) ведут себя по-разному.

Базовый набор команд для первичной диагностики на клиенте:

nfsstat -rc
nfsstat -m
cat /proc/mounts | grep nfs

На сервере параллельно смотрите CPU, сеть, диск и очереди, чтобы понять, где именно предел (линк, IOPS, latency, блокировки, CPU на обработку).

Типовые проблемы и быстрые чек-листы

«NFS медленный на больших файлах»

• Проверьте, что используется TCP и согласованы большие rsize/wsize.
• Проверьте MTU/PMTUD: симптомы — провалы скорости, ретраи, нестабильность при больших блоках.
• Подумайте про nconnect при многопоточном чтении/записи.

«Много мелких файлов — всё тормозит»

• Смотрите на метаданные: кэш атрибутов (actimeo), нагрузка на сервер, latency.
• Проверяйте, не создают ли приложения лишние операции (массовые stat(), open()).
• Сборку/деплой иногда проще ускорить изменением процесса (артефакты, rsync), чем тюнингом NFS.

«Подвисает при проблемах сети»

• Проверьте, что mount использует hard осознанно, а таймауты не слишком агрессивны.
• Для критичных путей закладывайте поведение приложения при I/O stall: healthchecks, таймауты, корректное завершение.
• Если это частая история — улучшайте сеть/маршрутизацию, а не только NFS-опции.

Рекомендованная стратегия выбора настроек

1. Определите требования: допустимы ли ошибки I/O, допустима ли потеря последних секунд данных, важнее latency или throughput.
2. Выберите протокол: по умолчанию v4.1, v3 — только по необходимости.
3. Настройте базу: TCP, вменяемые таймауты, hard для важных данных.
4. Подберите rsize/wsize под вашу сеть и файлопоток.
5. Решите вопрос async на сервере только после понимания рисков и тестов.
6. Проведите нагрузочные тесты под реальным паттерном и проверьте восстановление после реконнекта.

Вывод

NFS в Linux можно настроить как «надёжно и предсказуемо», так и «максимально быстро», но эти цели часто конфликтуют. Для большинства современных задач разумная отправная точка — NFS v4.1 с TCP, аккуратными таймаутами и осознанным подходом к caching и блокировкам. Дальше прирост throughput чаще всего дают корректные rsize/wsize, параллелизм (включая nconnect где уместно) и здоровая сеть. А вот async стоит включать только там, где риск потери данных действительно и формально приемлем.