Я использую 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, но мой опыт работы с другими протоколами обмена файлами в сети говорит о том, что производительность в сценарии «много маленьких файлов» страдает почти всегда. Вы сталкиваетесь с задержкой в оба конца, а для большой группы файлов эта задержка складывается.
Есть много причин, по которым передача большого количества маленьких файлов всегда будет медленнее, чем передача одного большого файла. При чтении файлы с большей вероятностью будут разбросаны по диску, и для их получения потребуется поиск повсюду. Как упоминал Эван, в случае NFS (или любой другой файловой системы!) Также используются метаданные, что также усложняет ситуацию.
Вы можете попробовать увеличить свой rsize и wsize параметры для монтирования NFS и посмотрите, поможет ли это немного повысить производительность. Также проверьте этот вопрос по настройке NFS для минимальной задержки, поскольку в нем есть много полезных советов, которые помогут в случае передачи большого количества небольших файлов.
Вы пробовали использовать другую файловую систему, например XFS? Это решило все мои проблемы при выполнении очень большого количества небольших передач блоков iSCSI. Понятия не имею почему.
Кроме того, iSCSI / NFS обычно настраивается для довольно больших фреймов данных (jumbo-фреймы и т. Д.), Это может повредить вам, если вы копируете крошечные файлы по одному. Возможно, вам поможет тарирование с последующим переносом.
Убедитесь, что вы используете TCP-соединение ( монтировать -t nfs -o tcp host: / mount / target ). Производительность современных систем не пострадает, но небольшие операции ввода-вывода могут значительно улучшиться, если ваша сеть загружена.
И вам также следует попробовать другую файловую систему; ext3 в основном самый медленный из всех. Он солидный, хорошо известный, но для файлового сервера совершенно не годится. XFS намного лучше, и reiserfs также намного лучше при небольших операциях ввода-вывода.
Если вы хотите передать большое дерево каталогов небольших файлов через NFS и можете войти на сервер, лучший способ сделать это - создать tar-файл, который автоматически извлекается на клиенте, как показано ниже:
tar c mydirectory | ssh user @ host tar -xf - -C destdir
Таким образом, по сети передается только один «файл», и вы сразу же получаете все свои файлы на хосте.
Чтобы добавить к ответу Эвана, у вас также есть все накладные расходы по созданию метаданных (записи каталога и т.д.) для каждого файла, который вы копируете.
Аналогичное решение как Ответ Криса будет периодически синхронизировать ваши файлы с клиентами. Если вы хотите внести двусторонние изменения, вы также можете использовать unison.
Проблема в том, что ваша доля экспортируется с sync вариант (по умолчанию). Использовать async чтобы значительно ускорить запись. См. Nfs.sourceforge.net/nfs-howto/ar01s05.html