целенаправленная скорость сети по LAN

У меня была аналогичная ситуация в прошлом, и мой способ решить состоял в том, чтобы вынудить Солярис и Linux смонтировать NFS v3 вместо v4.

Со стороны Соляриса можно отредактировать/etc/default/nfs и установить переменные для стороны сервера к серверу и принять только сторону NFS v3.

Не может помнить имена переменных, но это сам объяснительное.

Тест Вы сделали действительно ли копирование, является единственным большим файлом или несколькими файлами? Если бы это - несколько файлов, я не был бы удивлением, но если это - единственный файл, чем да.

Кроме того, какую базовую систему хранения Вы имеете? отдельный диск? установка набега? это - также влияние Ваша производительность.

Как быстро может базовые данные по запасам файловой системы? Сам NFS может переместить данные более быстро, чем Вы видите, который предполагает, что существуют другие узкие места. Можно убедить себя в этом при помощи iperf подтверждать, что сеть может передать более высокую пропускную способность потоком.

Я вошел бы в solaris систему и скопировал бы файл с файловой системы, которую Вы экспортируете в/dev/null, чтобы видеть, как быстро можно передать его потоком. Обратите внимание, что необходимо будет приложить некоторое усилие, чтобы не сделать этот тест чтения файла, который уже находится в кэше файловой системы. С другими файловыми системами Вы можете umount/mount для лишения законной силы кэша, но что один может быть недостаточным для ZFS.

Необходимо знать о возможностях каждой части стека. Какие диски составляют файловую систему для доли NFS? SAS? SATA? SSD? Какой тип и размер и скорость об/мин каждого? вращательная задержка? Действительно ли это - диск 4k? ZFS оптимизирован для 512-байтовых дисков и там известен проблемы с производительностью с помощью нового "усовершенствованного формата" диски.

Какой размер является Вашей рабочей нагрузкой ввода-вывода? Это также влияет, как быстро Ваше устройство хранения данных появится.

От просто перспективы устройства хранения данных, эти вопросы будут влиять, как быстрые данные могут быть записаны в и считаны с внутренних дисков. Например, скажем, Ваша доля NFS поступала из файловой системы на диске SATA на 7 200 об/мин 1 ТБ, и что Ваш размер рабочей нагрузки составляет 64 КБ и главным образом случаен.

Random Workload, 64 KB IO size
--------------------------------------------------------------------------------
Average Read Seek Time:        8.4 ms
Average Write Seek Time:       8.9 ms
Rotational latency:           .120 ms
Average Latency:             4.166 ms
Average Read Service Time:  12.566 ms
Average Write Service Time: 13.066 ms
--------------------------------------------------------------------------------
Best Case Read IOPs:           79.000
Best Case Write IOPs:          76.000
--------------------------------------------------------------------------------
Best Case Read Throughput:  4.937 MB/s
Best Case Write Throughput: 4.750 MB/s
--------------------------------------------------------------------------------
Real World Read IOPs:         55.300
Real World Write IOPs:        53.200
--------------------------------------------------------------------------------
Real World Read Throughput:  3.325 MB/s
Real World Write Throughput: 3.325 MB/s
--------------------------------------------------------------------------------

Это даст Вам общее представление о производительности реального мира, которую можно ожидать получать от отдельного диска в определенном размере рабочей нагрузки.

Можно повысить ту производительность при наличии кэша записи или монтировании файловой системы NFS асинхронно, так, чтобы подтверждения записи не требовались, прежде чем следующий ввод-вывод начинается (не, что я рекомендую это, поскольку это подвергает данные опасности).

После того как Вы понимаете производительность своего устройства хранения данных бэкенда, затем можно ли начать смотреть на дополнительные издержки, созданные NFS (это v3? v4? tcp? udp?), или SSH (какой алгоритм шифрования Вы используете? можно использовать более легкий алгоритм как arcfour для улучшения производительности), или сама сеть. У Вас есть дешевка 1GbE NIC? или качество сервера более высокого уровня NIC? Вы совместно используете это nic между многочисленными услугами? что-либо еще генерирует трафик в Вашей сети? Как насчет перегрузки сети, коллизий или высоких уровней повторной передачи?

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

Теперь, числа выше являются своего рода худшим вариантом развития событий, правильно? 100%-я случайная синхронная рабочая нагрузка. Если у Вас есть последовательная рабочая нагрузка, или можно повысить размер рабочей нагрузки IO, можно существенно повысить производительность. Например, если можно ударить размер IO к 128k, Вы удвоите свою производительность, и в зависимости от Вашего клиента NFS, Вы можете устанавливать rsize и wsize, к различным настройкам к проведению испытаний. Существует после всего точка убывающей доходности.

И если у Вас есть несколько дисков в зеркале или RAID, необходимо будет скорректировать числа для этого.

Производительность диска Реального мира почти никогда не, что печатается на стороне поля, что диск вошел.