цільова швидкість мережі через локальну мережу

У мене є система Solaris 11, яка має кілька експортів NFS, до яких звертаються інші мої системи в моїй локальній мережі. Я використовую систему Linux як клієнт для тестування.

Я написав швидкий сценарій, щоб перевірити швидкість читання, і я в середньому складає близько 110 Мбіт / с (або 13 МБ / с) в гігабітній локальній мережі. І я б подумав, що це може стати набагато швидше. SSH (scp) дає мені лише 3,8 Мб / с, але це з шифруванням.

http дає мені 11,5 М / с, аналогічно NFS. хіба це не так низько?

що може бути вузьким місцем у цих цифр?

NFS не може реально збільшити пропускну здатність, оскільки клієнт продовжує надсилати, будь ласка, надішліть мені стільки даних на сервер ( це обмежується кількома кілобайт) і чекає повного відповіді, перш ніж запитати більше, що означає мертві часи, коли всі черги порожні. Усі FS по мережі (CIFS, SSHFS) мають однаковий вигляд (і IIRC scp, а також, можливо, це лише sftp, я не можу згадати)

Окрім шифрувальних накладних витрат, sshє ще деякі обмеження продуктивності (детальніше див. Тут ).

HTTP, якщо ви не використовуєте клієнта, який виконує чіткі запити, повинен бути прямим TCP, тому не повинен мати такого роду обмеження. TCP повинен використовувати свій алгоритм контролю перевантаженості, щоб максимізувати пропускну здатність, уникаючи перевантажень. Незважаючи на те, що перші кілька кілобайт можуть передаватися повільно, ви повинні мати можливість збільшити пропускну здатність протягом декількох 10 секунд, якщо дві машини підключені через один і той же комутатор. Можливо, є якась низька якість мережі (наприклад, непарна втрата пакету).

Що ви можете спробувати:

• Перенесіть вміст /dev/zeroчерез звичайне TCP-з'єднання (використовуючи socatабо, ncнаприклад), щоб виключити шийку пляшки з доступом до FS.
• Перевірте статистику мережевого інтерфейсу на наявність помилок передачі та статистику стека TCP ( netstat -s)
• Тест за допомогою iperf(і TCP, і UDP).

У мене була схожа ситуація в минулому, і мій спосіб вирішити - змусити Solaris і Linux встановити NFS v3 замість v4.

З боку Solaris ви можете редагувати / etc / default / nfs та встановлювати змінні для сервера на сервері та приймати лише NFS v3.

Не можу запам’ятати назви змінних, але це само собою пояснюється.

Тест, який ви зробили, - це копіювання одного великого файлу чи кількох файлів? Якщо це декілька файлів, я не здивуюсь, але якщо це один файл, ніж так.

Крім того, який у вас є основний сховище? один диск? налаштування рейду? це також впливає на вашу ефективність.

З якою швидкістю базова файлова система може надавати дані? Сам NFS може переміщувати дані швидше, ніж ви бачите, що говорить про наявність інших вузьких місць. Ви можете переконатись у цьому, скориставшись iperf, щоб підтвердити, що мережа може передавати більшу пропускну здатність.

Я зайшов би в систему solaris і скопіював файл з файлової системи, яку ви експортуєте в / dev / null, щоб побачити, наскільки швидко ви можете передавати його. Зауважте, що вам потрібно докласти певних зусиль, щоб не зробити цей тест читання файлу, який вже є в кеші файлової системи. З іншими файловими системами ви можете налаштувати / змонтувати, щоб визнати недійсним кеш, але це одне може бути недостатнім для ZFS.

Ви повинні бути в курсі можливостей кожного шматка вашої стеки. Які диски складають файлову систему для спільного використання NFS? SAS? SATA? SSD? Який тип та розмір та швидкість обертання кожного? затримка обертання? Це привід 4 к? ZFS оптимізований для 512-байтових накопичувачів, і існують відомі проблеми з продуктивністю використання нових дисків «розширеного формату».

Який розмір вашої завантаженості вводу / виводу? Це також впливає на швидкість появи вашого сховища.

З точки зору суто зберігання, ці питання впливатимуть на швидкість запису даних та їх зчитування з резервних дисків. Наприклад, скажімо, що ваша NFS частка надходила з файлової системи на 7200 об / хв 1 TB SATA диска, і що ваш обсяг навантаження становить 64 КБ і в основному є випадковим.

Random Workload, 64 KB IO size
--------------------------------------------------------------------------------
Average Read Seek Time:        8.4 ms
Average Write Seek Time:       8.9 ms
Rotational latency:           .120 ms
Average Latency:             4.166 ms
Average Read Service Time:  12.566 ms
Average Write Service Time: 13.066 ms
--------------------------------------------------------------------------------
Best Case Read IOPs:           79.000
Best Case Write IOPs:          76.000
--------------------------------------------------------------------------------
Best Case Read Throughput:  4.937 MB/s
Best Case Write Throughput: 4.750 MB/s
--------------------------------------------------------------------------------
Real World Read IOPs:         55.300
Real World Write IOPs:        53.200
--------------------------------------------------------------------------------
Real World Read Throughput:  3.325 MB/s
Real World Write Throughput: 3.325 MB/s
--------------------------------------------------------------------------------

Це дасть вам уявлення про реальну продуктивність у світі, яку ви можете розраховувати отримати з одного диска при певному розмірі навантаження.

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

Як тільки ви зрозумієте продуктивність вашого резервного сховища, ви можете почати переглядати додаткові накладні витрати, створені NFS (це v3? V4? Tcp? Udp?), Або SSH (який алгоритм шифрування ви використовуєте? Ви можете використовувати легший алгоритм, як arcfour для підвищення продуктивності), або сама мережа. У вас є дешевий 1GbE NIC? або NIC якості сервера вищого класу? Ви поділяєте цю нік між кількома службами? ще щось генерує трафік у вашій мережі? Як щодо перевантаженості мережі, зіткнень або високих показників повторної передачі?

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

Тепер цифри, наведені вище, - це свого роду найгірший сценарій, правда? 100% випадкове синхронне навантаження. Якщо у вас є послідовне навантаження або ви можете збільшити розмір завантаженості вводу-виводу, ви можете різко підвищити продуктивність. Наприклад, якщо ви можете збільшити розмір вводу-виводу до 128 К, ви подвоюєте свою ефективність, і залежно від вашого клієнта NFS, ви можете встановити rsize та wsize для різних налаштувань для перевірки продуктивності. Адже є точка зменшення віддачі.

І якщо у вас є кілька дисків, у дзеркалі або RAID, вам доведеться відрегулювати свої номери для цього.

Дійсна продуктивність реального світу майже ніколи не надрукована збоку коробки, в яку входив диск.