Повільна продуктивність передачі малих файлів 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 зазвичай налаштовується для досить великих фреймів даних (джомбові кадри тощо), це може зашкодити вам, якщо ви копіюєте крихітні файли один за одним. Можливо, тарінг та передача допоможуть вам.

Перевірте, чи використовується TCP-з'єднання ( mount -t nfs -o tcp host: / mount / target ). На продуктивність сучасних систем це не вплине, але невеликі введення-виведення можуть значно покращитися при завантаженні вашої мережі.

А також слід спробувати якусь іншу файлову систему; ext3 - це в основному найповільніше. Це твердо, добре відомо, але цілком непридатне для файлового сервера. XFS набагато краще, а reiserfs також набагато краще при невеликих введеннях.

Якщо ви хочете перенести велике дерево каталогів невеликих файлів через NFS, і ви можете увійти на сервер, найкращий спосіб зробити це - зробити файл tar, який автоматично витягується на клієнті, таким чином:

тар c мідідиректорія | ssh user @ host tar -xf - -C destdir

Таким чином, лише один "файл" передається через мережу, і ви негайно маєте всі свої файли на хості.

Просто для додання відповіді Евана, у вас також є всі витрати на створення метаданих (записи каталогів тощо) для кожного файлу, який ви копіюєте.

Аналогічним рішенням, як відповідь Кріса, було б періодично rsync ваші файли до клієнтів. Якщо ви хочете внести двосторонні зміни, ви також можете скористатися унісон.

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