Падение скорости записи NFS в случае ошибочной процедуры COMMIT

Падение скорости записи NFS в случае ошибочной процедуры COMMIT

Во-первых, извините за публикацию очевидного учебного вопроса. Я знаю, что это плохая привычка, но я надеюсь, что мне все еще помогут здесь, потому что я провел кучу исследований и не смог найти на него ответа.

Theсценарийвыглядит так: NFS-клиент записывает один файл размером 50 ГБ на NFS-сервер. После записи 4 ГБ со средней скоростью 125 МБайт/с она падает до 12 МБайт/с.

Вопрос: Как вы можете это объяснить?

Theданныйотвечатьна вопрос таков: После 4 ГБ записи Сервер не отвечает на COMMIT, а Клиент периодически отправляет COMMIT, пока Сервер не ответит на него, потому что Клиент хочет очистить свой кэш. В этот период времени Скорость передачи данных падает до уровня самого медленного элемента.

Все, что я смог найти о процессе COMMIT, это такое объяснение:

Клиент записывает данные, и когда данные передаются на сервер, клиент отправляет COMMIT. Сервер записывает данные в стабильное хранилище и отвечает на COMMIT с помощью verf-Cookie. Если cookie НЕ отличается от cookie клиента, клиент может очистить свой кэш.

Итак, вотмой вопрос: Правда ли, что если сервер не отвечает на COMMIT-Procedure отправкой verf-cookie, то клиент периодически отправляет COMMIT и скорость передачи данных значительно падает? Если да, то до какого уровня падает скорость передачи данных. Я не могу сделать вывод из ответа, до какого уровня падает скорость передачи данных.

решение1

Я думаю, что происходит следующее:

Данные, отправленные клиентом, записываются в кэш FS на стороне сервера. После отправки запроса COMMIT эти данные начинают сбрасываться на постоянное хранилище (DISK). В зависимости от производительности диска сервера это может занять некоторое время. Допустим, производительность диска составляет 300 МБ/с. Для сброса 4 ГБ потребуется 13 с. Если это время больше тайм-аута NFS, то клиент может отправить еще один запрос COMMIT, предполагая, что первый будет утерян. Верификатор COMMIT/WRITE используется для того, чтобы гарантировать, что сервер не будет перезагружен между этими операциями.

В таком случае вы можете сделать следующее:

  • увеличить время ожидания NFS на клиенте, указаввремя=вариант монтирования. Хотя это будет толькоисправитьповторные попытки КОММИТА.
  • сообщить серверу о необходимости начать сброс данных достаточно рано и избежать задержек в журнале.

использовать

sysctl -w vm.dirty_background_ratio=0
sysctl -w vm.dirty_ratio=0
sysctl -w vm.dirty_background_bytes=67108864
sysctl -w vm.dirty_bytes=536870912

Размеры следует настраивать в соответствии с производительностью ввода-вывода сервера и всей сети.

Для управления тем, когда ядро ​​начинает сбрасывать данные на диск на сервере и отправлять их на сервер на стороне клиента.

ПРИМЕЧАНИЕ: эти параметры являются глобальными и повлияют на все файловые системы.

Связанный контент