Я забочусь о нескольких серверах, которые относительно интенсивно используют файловую систему NFS.
Во время кризиса один сервер отправляет фильтру около 2 тыс. Операций чтения + 2 тыс. Операций записи в секунду. Согласно nfsiostat, в это время RTT чтения и записи увеличиваются с обычных 5-10 мс до 50-100 мс как для чтения / записи. Среднее время выполнения в соответствии с nfsiostat резко отличается для чтения и записи: чтение около 200 мс, запись от 100 до 200 с.
Теперь из того небольшого, что я понимаю, среднее время выполнения в nfsiostat - это, по сути, RTT + время ядра (очереди RPC и т. Д.). Говоря о RPC - я вижу точно такое же поведение на RH5.8 (бэклог RPC около 5 КБ при кранче) и RH6.3 (бэклог RPC 0 всегда).
Итак - вопрос: в чем может быть причина того, что время выполнения чтения / записи NFS так сильно отличается?
(Вызовы NFS выполняются проприетарным приложением, в котором у меня нет особой видимости. То же самое относится и к файловому серверу (NetApp - аутсорсинг). Трассировка ядра, вероятно, тоже не будет вариантом)
Заранее большое спасибо.
РЕДАКТИРОВАТЬ: чтобы уточнить, и поскольку я получаю некоторые ответы, касающиеся производительности NFS в целом - единственная часть, которая меня действительно интересует, это: согласно nfsiostat doco RTT - это «... продолжительность с момента, когда ядро клиента отправляет запрос RPC, до времени он получает ответ ". а Avg Exe - это «... время с момента, когда клиент NFS выполняет запрос RPC к своему ядру, до завершения запроса RPC, включая время RTT, указанное выше». (http://man7.org/linux/man-pages/man8/nfsiostat.8.html).
Мое (возможно, наивное) понимание состоит в том, что после RTT сервер не работает. Так что же делает клиент NFS, что Avg Exe настолько отличается для чтения / записи, когда RTT одинаков?
На основе описанного сценария возможно наличие нескольких факторов. sync и async параметры могут существенно повлиять на производительность, как и nolock вариант при монтировании NFS.
На производительность также могут повлиять проблемы с правами собственности на файлы и разрешениями, связанные с ACL для файлов и / или использованием root_squash и no_root_squash варианты при монтаже. Хотя, если бы это было так, вероятно, где-нибудь в журналах были бы свидетельства этого.
Также могут возникнуть проблемы с перемещением файлов в память и из памяти. В зависимости от последовательности операций и количества физической и виртуальной памяти также может происходить много сбоев.
Если трафик продолжается и файловые операции не очищены должным образом / зависают / занимает слишком много времени для завершения операций записи, количество файлов, открытых в данный момент, может начать выходить за пределы, поддерживаемые ядром, это можно проверить, запустив:
cat /proc/sys/fs/file-max
Если это значение низкое на сервере или клиенте NFS, возможно, стоит увеличить его, чтобы посмотреть, улучшится ли производительность. В зависимости от сетевой среды реализация определенных политик QoS потенциально может повлиять на производительность (хотя, вероятно, маловероятно).