Налаштування стека клієнтів / серверів NFS

У мене є сервер CentOS 5 VMWare, який підключається до машини OpenSolaris 2009.06 через NFS, що містить зображення дисків. Мої віртуальні машини, здається, пов'язані повільним IO, тому я хотів би зробити все можливе для оптимізації з'єднання.

Я не впевнений у найкращому способі вимірювання пропускної спроможності у виробничій системі, але деякі ненаукові тести з використанням dd bs=1024k count=400показують локальні (OpenSolaris) записи ~ 1,6 Гб / с, а віддалені (CentOS) записують ~ 50 Мб / с. Я думаю, що вони нижчі за те, що я отримую насправді, оскільки 7 ВМ зараз працюють над з'єднанням.

В даний час дві машини є безпосередньо підключеними gigE з джомбовими кадрами, включеними в обох NIC (MTU = 9000). Крім цього, оптимізації не проводилися. NFS mount / export використовується за замовчуванням.

З чого слід почати крутити ручки, щоб поліпшити продуктивність?

Для уточнення, ви отримуєте 50MB / сек з NFS через одне Gb-з'єднання Ethernet?

І хост-сервер працює CentOS з встановленим VMware Server, який, в свою чергу, працює 7 VM? Чи є певна причина, що ви разом із CentOS і VMware Server поєднувались, а не VMware ESXi, що є більш високою продуктивністю?

50 Мб / сек не є великим, але це не набагато нижче того, що ви очікували від одного мережевого кабелю Gb - після того, як ви вкладете налаштування NFS, про які люди згадали вище, ви будете дивитися, можливо, 70- 80 Мб / сек. Параметри по рядку:

"ro, hard, intr, retrans = 2, rsize = 32768, wsize = 32768, nfsvers = 3, tcp"

ймовірно, для вас розумні на обох кінцях системи.

Щоб отримати вище, вам потрібно буде роздивитись об'єднання мережевих карт на пари, що повинно збільшити пропускну здатність приблизно на 90%. Ви , можливо , буде потрібно комутатор , який підтримує 802.3ad , щоб отримати кращу продуктивність при агрегації каналів .

Я б хотів сказати, що ваша пропускна здатність IO у вікні OpenSolaris звучить підозріло високо, 12 дисків, ймовірно, не підтримують 1,6 Гб / сек пропускної здатності, і Solaris + ZFS може сильно кешуватись.

Для наших машин RHEL / CentOS 5 ми використовуємо наступні прапори кріплення

nfsvers = 3, tcp, timeo = 600, retrans = 2, rsize = 32768, wsize = 32768, жорсткий, intr, timeat

Новіша версія ядра Linux підтримує ще більші параметри rsize / wsize, але 32k - це максимум для ядра 2.6.18 в EL5.

На серверах NFS, принаймні, для Linux no_wdelay нібито допомагає, якщо у вас є дисковий контролер з BBWC. Крім того, якщо ви використовуєте прапор noatime на клієнтах, можливо, має сенс також монтувати файлові системи на серверах і в режимі noatime.

І, як уже говорилося, не турбуйтеся з UDP. У мережах з високою швидкістю (1GbE +) є невеликий, але не нульовий, шанс перетворення послідовного номера, що спричинить пошкодження даних. Також, якщо є можливість втрати пакету, TCP буде працювати краще, ніж UDP.

Якщо ви не переживаєте про цілісність даних настільки, опція експорту "async" може стати головним поліпшенням продуктивності (проблема з async полягає в тому, що ви можете втратити дані, якщо сервер вийде з ладу).

Також, принаймні для сервера Linux, вам потрібно переконатися, що у вас працює достатньо потоків серверів NFS. За замовчуванням 8 просто занадто низький.

Я колись робив тест з dell r710, 1 процесор, 4 ГБ оперативної пам’яті, 6 дисками SATA з RAID-10. Клієнт був sun x2100, як із CentOS 5.3, так і з nfs-парамами, як згадувалося вище

"ro, hard, intr, retrans = 2, rsize = 32768, wsize = 32768, nfsvers = 3, tcp"

монтується з обох боків у нічний час.

Я також нарікав на nfsds до 256 і використовував планувальник noop для рейдового контролера perc6. Інша річ, яку я зробив, - вирівняти перегородки за розміром смуги 64K нальоту-контролера.

тоді я виміряв продуктивність nfs з dd - для читань я міг би заповнити трубу gigE, але для записів я міг отримати лише трохи кращі результати як ви. З включеною асинхронією я міг отримати від 70 до 80 Мб / с, але асинхронізація не була для мене варіантом.

Можливо, ви не можете отримати більше nfs із посилання gigE?

Спробуйте це: тимчасово вимкніть журнал намірів ZFS (ZIL) на сервері OpenSolaris NFS за допомогою наступних двох кроків

1. echo zil_disable/W0t1 | mdb -kw
2. знову встановіть тестову секцію

Потім ще раз тестуйте. Ви можете використовувати zilstat, щоб переконатися, що дійсно більше немає IO для ZIL. Якщо тест працює швидше, ви знаєте, що проблема продуктивності має щось спільне із ZIL. Якщо вона все ще працює повільно, ви знаєте, що ZIL не є винуватцем, і використання SSD для ZIL також не допоможе. Дивіться посібник з налаштування зла ZFS для отримання додаткової інформації про ZIL.

Іншим варіантом може бути захоплення мережевого трафіку (наприклад, з Wireshark) і перевірити, чи є якісь проблеми, наприклад, з кадрами Jumbo. Переконайтеся, що пакети на дроті виглядають так, як ви очікуєте від конфігурації. Чи відбувається якась погана фрагментація? Чи є повторні передачі?

Підвищення розмірів корисного навантаження для читання та запису може допомогти. Особливо в поєднанні з джамбо-рамками.

Я схильний вважати 32k оптимальним.

rsize=32768,wsize=32768

Перехід на транспорт UDP, звичайно, швидше, ніж на TCP, оскільки це економить накладні витрати на управління передачею. Але він застосовується лише в надійних мережах і там, де NFSv4 не використовується.

Продуктивність NFS на ZFS значно покращується за допомогою використання SSD для журналу намірів ZFS (ZIL), оскільки це зменшує затримку операцій. Цей потік про продуктивність VMWare NFS щодо продуктивності ZFS у списках розсилки OpenSolaris NFS та ZFS містить додаткову інформацію, включаючи інструмент орієнтиру, щоб перевірити, чи є ефективність ZIL найвищим місцем.

Команда FYI dd запише в кеш-пам'ять, а не на диск, це ви можете отримати шалені числа, як 1.6G / s, тому що ви пишете в ОЗУ, а не диск на Solaris, ви можете використовувати "-oflag = sync", щоб змусити записувати на диск