Низкая производительность передачи небольших файлов по NFS

Я использую Openfiler 2.3 на дисках HP ML370 G5, Smart Array P400, SAS в сочетании с RAID 1 + 0.

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

Простой тест с использованием dd:

 $ dd if=/dev/zero of=outfile bs=1000 count=2000000
 2000000+0 records in
 2000000+0 records out
 2000000000 bytes (2.0 GB) copied, 34.4737 s, 58.0 MB/s

Я вижу, что можно достичь умеренной скорости передачи (58,0 МБ / с).

Но если я скопирую каталог, содержащий много маленьких файлов ( .phpи .jpgоколо 1-4 КБ на файл) общим размером ~ 300 МБ, cpпроцесс завершится примерно через 10 минут.

NFS не подходит для передачи небольших файлов, как описано выше? Или есть какие-то параметры, которые нужно отрегулировать?

Есть много причин, почему передача большого количества маленьких файлов всегда будет медленнее, чем передача одного большого файла. При чтении файлы с большей вероятностью будут разбросаны по всему диску, что потребует повсеместного поиска, чтобы получить их. Как упоминал Эван, в случае NFS (или любой другой файловой системы в этом отношении!) Также используются метаданные, что также усложняет ситуацию.

Вы можете попробовать увеличить ваши параметры rsizeи wsizeпараметры до монтирования NFS и посмотреть, не снизит ли это производительность. Также ознакомьтесь с этим вопросом о настройке NFS для минимальной задержки, поскольку в нем содержится много полезных советов, которые помогут в случае множества небольших передач файлов.

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

Вы пробовали с другой файловой системой, например, XFS? Это решило все мои проблемы при выполнении большого количества небольших передач блоков iSCSI. Понятия не имею почему.

Кроме того, iSCSI / NFS обычно настроен на довольно большие кадры данных (большие кадры и т. Д.), Это может повредить вам, если вы копируете крошечные файлы по одному. Может быть, tar'ing, а затем передача поможет вам.

Убедитесь, что вы используете TCP-соединение ( mount -t nfs -o tcp host: / mount / target ). На производительность современных систем это не повлияет, но небольшие операции ввода-вывода могут значительно улучшиться, если ваша сеть загружена.

И вам также следует попробовать другую файловую систему; ext3 в основном самый медленный из всех. Это хорошо, хорошо известно, но совершенно не подходит для файлового сервера. XFS намного лучше, а reiserfs также намного лучше при небольших операциях ввода-вывода.

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

tar c mydirectory | ssh user @ host tar -xf - -C destdir

Таким образом, по сети передается только один «файл», и вы сразу же получаете все свои файлы на хосте.

Просто чтобы добавить к ответу Эвана, у вас также есть все накладные расходы на создание метаданных (записи каталога и т. Д.) Для каждого файла, который вы копируете.

Решение, аналогичное ответу Криса, будет периодически пересылать ваши файлы клиентам. Если вы хотите внести двусторонние изменения, вы также можете использовать унисон.

Проблема в том, что ваша доля экспортируется с syncопцией (по умолчанию). Используйте asyncдля ускорения записи значительно. См. Nfs.sourceforge.net/nfs-howto/ar01s05.html