NFS погана ефективність запису


20

У мене є два машини, підключені до 10Gbit Ethernet. Нехай один з них буде сервером NFS, а інший - клієнтом NF.

Тестування швидкості мережі через TCP iperfпоказує ~ 9,8 Гбіт / с пропускну здатність в обох напрямках, тому мережа в порядку.

Тестування продуктивності диска NFS-сервера:

dd if=/dev/zero of=/mnt/test/rnd2 count=1000000

Результат - 150 Мбіт / с, тому диск добре працює для запису.

Сервери /etc/exports:

/mnt/test 192.168.1.0/24(rw,no_root_squash,insecure,sync,no_subtree_check)

Клієнт змонтує цю спільну частку на її локальному рівні /mnt/testз такими параметрами:

node02:~ # mount | grep nfs
192.168.1.101:/mnt/test on /mnt/test type nfs4 (rw,relatime,sync,vers=4.0,rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp,port=0,timeo=600,retrans=2,sec=sys,clientaddr=192.168.1.102,local_lock=none,addr=192.168.1.101)

Якщо я спробую завантажити великий файл (~ 5Gb) на клієнтській машині з NFS, я отримаю ~ 130-140 Мбіт / с, що є близьким до продуктивності локального диска сервера, тому це задовільно.

Але коли я намагаюся завантажити великий файл на загальну частину NFS, завантаження починається з ~ 1,5 Мбайт / с, повільно збільшується до 18-20 Мбайт / с і припиняє збільшуватися. Іноді частка "зависає" за пару хвилин до того, як фактично розпочнеться завантаження, тобто трафік між хостами стає близьким до нуля, і якщо я виконую ls /mnt/test, він не повертається протягом хвилини-двох. Потім lsкоманда повертається і завантаження починається з початковою швидкістю 1,5 Мбіт / с.

Коли швидкість завантаження досягає максимуму (18-20 iptraf-ngМбіт / с), я запускаюсь, і він показує ~ 190 Мбіт / с трафіку в мережевому інтерфейсі, тому мережа тут не є вузьким місцем, як і жорсткий диск сервера.

Що я спробував:

1. Встановіть сервер NFS на третьому хості, який був підключений лише до 100 Мбіт Ethernet NIC. Результати є аналогічними: DL показує хороші показники та майже повне використання 100 Мбіт мережі, завантаження не працює швидше, ніж сотні кілобайт в секунду, завдяки чому використання мережі дуже низьке (2,5 Мбіт / с відповідно до iptraf-ng).

2. Я намагався налаштувати деякі параметри NFS:

  • sync або async

  • noatime

  • ні hard

  • rsizeі wsizeмаксимум у моїх прикладах, тому я спробував зменшити їх у кілька кроків до рівня 8192

3. Я намагався переключити клієнтські та серверні машини (налаштувати сервер NFS на колишній клієнт і навпаки). Більше того, є ще шість серверів з однаковою конфігурацією, тому я намагався встановити їх один до одного в різних варіаціях. Той самий результат.

4. MTU = 9000, MTU = 9000 і 802.3ad агрегація ланок, агрегація ланок з MTU = 1500.

5. настроювання sysctl:

node01:~ # cat /etc/sysctl.conf 
net.core.wmem_max=16777216
net.core.rmem_max=16777216
net.ipv4.tcp_rmem= 10240 873800 16777216
net.ipv4.tcp_wmem= 10240 873800 16777216
net.ipv4.tcp_window_scaling = 1
net.ipv4.tcp_timestamps = 1
net.ipv4.tcp_sack = 1
net.core.netdev_max_backlog = 5000

Той самий результат.

6. Гора від localhost:

node01:~ # cat /etc/exports
/mnt/test *(rw,no_root_squash,insecure,sync,no_subtree_check)
node01:~ # mount -t nfs -o sync localhost:/mnt/test /mnt/testmount/

І тут я отримую той самий результат: завантаження з нього /mnt/testmount/відбувається швидко, завантаження /mnt/testmount/відбувається дуже повільно, не швидше 22 Мбіт / с, і перед тим, як почати передачу, є невелика затримка. Чи означає це, що мережевий стек працює бездоганно і проблема в NFS?

Все це не допомогло, результати не суттєво відрізнялися від конфігурації за замовчуванням. echo 3 > /proc/sys/vm/drop_cachesбув виконаний до всіх випробувань.

MTU всіх NICS на всіх 3 хостах - 1500, нестандартне налаштування мережі не проводиться. Перемикач Ethernet - це Dell MXL 10 / 40Gbe.

ОС є CentOS 7.

node01:/mnt/test # uname -a
Linux node01 3.10.0-123.20.1.el7.x86_64 #1 SMP Thu Jan 29 18:05:33 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux

Які налаштування мені не вистачає? Як змусити NFS писати швидко і без зависань?


1
У вас є досить добре закруглений тестовий випадок, але я б спробував встановити на сам сервер і записати звідти, таким чином ви зможете зрозуміти, чи винен стек NFS або стек мережі. Крім того, спробуйте переключити сервер і клієнта (експортувати з клієнта, встановити на сервер), а також, використовуючи зовсім іншого клієнта. розшарування процесів сервер / клієнт нічого не виявило?
Далібор Карлович

@ DaliborKarlović Я спробував все, окрім напруги, і додав інформацію до питання. Монтаж із localhost працює повільно, тому мережеві стеки та комутатори, здається, не винні. Я використовую простір ядра NFS і Operation not permittedнамагаюся приєднати strace до процесу NFS.
Сергій

Я припускаю, що це означає, що ви можете повністю виключити мережевий стек (але вам потрібно буде приєднати крок, щоб переконатися в цьому). Ви повинні мати можливість відстежувати будь-який процес як користувач root, якщо певна помилка не потрапляє на нього .
Далібор Карлович

@ DaliborKarlović Звичайно, я намагаюся страйк як корінь. Я можу приєднатися до будь-якого процесу простору користувачів, але не до ядра простору. Але яку інформацію я можу отримати з її результату? Я припускаю, що він дасть сотні тисяч рядків виводу, якщо я приєднаю його до NFS і почну завантажувати. Чи варто звертати увагу на ненульові значення повернення?
Сергій

Ви маєте рацію, я не задумувався над тим, щоб це був процес не в користуванні. Я очікував би побачити, що він робить, поки він "висить" на початку передачі, це може бути щось тривіальне, як неправильно налаштований зворотний пошук DNS.
Далібор Карлович

Відповіді:


3

Ви використовуєте опцію синхронізації у своєму експортному звіті. Це означає, що сервер підтверджує операції запису лише після того, як вони фактично записані на диск. Зважаючи на те, що у вас є спінінг-диск (тобто немає SSD), для цього в середньому потрібно щонайменше 1/2 обертання диска за операцію запису, що є причиною уповільнення.

Використовуючи налаштування async, сервер негайно підтверджує операцію запису для клієнта, коли він обробляється, але ще не записаний на диск. Це трохи ненадійніше, наприклад, у разі відключення електроенергії, коли клієнт отримав доступ до операції, яка не відбулася. Однак, це забезпечує величезний приріст швидкості запису.

(редагувати) Щойно я побачив, що ви вже протестували параметри async vs sync. Однак я майже впевнений, що це причина вашої деградації продуктивності - колись у мене були точно такі ж показання із встановленням ідентичності. Можливо, ви перевірите це ще раз. Ви дали параметр async в операторі експорту сервера ТА в операції монтування клієнта одночасно?


+1 Найімовірніше пояснення: синхронізація була неправильно відключена.
Девід Шварц

2

Це може бути проблема, пов’язана з розміром і затримкою пакету. Спробуйте наступне:

Звіт повертає ваші результати.


Я спробував джамбо-кадри з MTU = 9000, але результати були однакові. Я також спробував агрегацію посилань з 802.3ad, знову ніяких змін. Тому я змінив усі ці налаштування, щоб максимально наблизитися до стану за замовчуванням. Також я намагався налаштувати це net.core.*і net.ipv4.*sysctls, але, можливо, я зробив занадто мало експериментів. Гаразд, я зроблю ще кілька тестів і звітую.
Сергій

Я ще раз спробував налаштувати sysctls і на сервер, і на клієнт, але це не допомогло.
Сергій

Ви пробували з UDP як транспортний протокол?
shodanshok

Я спробував UDP (proto = udp у параметрах монтажу), але він працює навіть на 1-2 Мбайт / с повільніше, ніж TCP. Результат був однаковим кріпленням від localhost та від віддаленого хоста.
Сергій

2

http://veerapen.blogspot.com/2011/09/tuning-redhat-enterprise-linux-rhel-54.html

Налаштування планувальника Linux для систем з апаратним RAID та зміна за замовчуванням з [cfq] на [noop] покращує введення / виведення.

Використовуйте команду nfsstat, щоб обчислити відсоток читання / запису. Встановіть співвідношення кеш-пам'яті контролера RAID.

Для великих навантажень вам потрібно збільшити кількість потоків серверів NFS.

Налаштуйте потоки nfs для запису без зволікань на диск за допомогою параметра no_delay.

Попросіть ядро ​​Linux просвітитися якомога швидше, щоб записи зберігалися якомога менше. У ядрі Linux частотою запису брудних сторінок можна керувати двома параметрами.

Для швидшого запису на диск використовуйте параметр файлова система data = journal і запобігайте оновленням часу доступу до файлів, що само по собі призводить до отримання додаткових даних, записаних на диск. Цей режим є найшвидшим, коли дані потрібно читати і записувати на диск одночасно, коли він перевершує всі інші режими

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.