Каталог Поиск 0 Сравнить 0 Закладки 0 Корзина Войти
Каталог
105082, Москва, ул. Фридриха Энгельса, 75с21, БЦ Бауманский ИТКОЛ
Пн - Пт: с 09-00 до 18-00 Сб: с 10-00 до 18-00 Вс: выходной
Страницы: 1
RSS
UNAS-Pro: Jumbo Frames и скорость передачи данных. Как вы знаете, UNAS-Pro отлично подходит для передачи больших объемов данных. Особенно это касается использования Jumbo Frames. **Что такое Jumbo Frames?** Jumbo Frames – это Ethernet-кадры большего ра, UniFi Drive
 
Мой свитч ( USW Pro Max) и клиентские устройства настроены на использование jumbo frames, но производительность чтения с UNAS эквивалентна примерно 1.5Gbit. Это верно, независимо от того, используется ли 10G SFP+ порт или 2.5Gbe порты. Я вижу, что MTU между свитчем и клиентом согласовывается на 9000 байт с MSS около 8k. UNAS подключен к тому же свитчу, что и клиент, с помощью 10bit SFP кабеля от ubiquity. Исходя из количества и скорости дисков, я должен иметь возможность читать/копировать файл со скоростью 8Gbit или лучше, вместо 1.5Gbit, которую я вижу. Поддерживает ли UNAS-Pro Jumbo Frames? Есть какие-нибудь предложения по улучшению производительности чтения? Спасибо.
 
В общем-то, всё закончилось тем, что проблема была в Jumbo frames. Включил их в UniFi, и это помогло, по крайней мере, для iperf. Пока не было возможности проверить, как это влияет на реальную передачу файлов.
 
Я смог добиться скорости чтения/записи в 600 МБ при следующих условиях:
Jumbo frames = отключены
Протокол = SMB
10Gig endpoint (Ethernet) ↔ USW Pro XG ↔ UNAS-Pro (SFP+)

В UNAS-Pro установлено 4x 24ТБ HDD с вращением 7200 об/мин и скоростью 6 Гигабит. Я специально не хотел ставить слишком мало дисков, так как это негативно повлияло бы на производительность, но мне кажется, что это программный RAID, так как нет выделенного контроллера. Полагаю, что на данном этапе узким местом является то, что каждый HDD имеет максимальную скорость чтения/записи 6 Гигабит, поэтому моя скорость чтения/записи по SMB составляет около 600 МБ/сек. Как и указано в NAS в верхней части веб-интерфейса, производительность HTTP была медленнее, чем SMB, особенно при загрузке.
 
Ты продвинулся с этим вопросом? У меня та же проблема, получаю только ±1.5Gbits/s на SFP+ порту. Кстати, на этой странице советуют, что jumbo frames не требуются: https://help.ui.com/hc/en-us/articles/30360368435479-Optimizing-Your-UNAS-for-High-Speed-Performance-and-Efficient-Storage. Еще я попробовал использовать скрипт fio-cdm для тестирования скорости чтения/записи, и получается около 500MB/s на чтение и около 50MB/s на запись, так что хотя бы чтение выше, чем результат теста iperf на 1.5Gb/s. Всё ещё не понимаю, что здесь происходит.
 
Спасибо за предложение fio, гляну.
 
Я не особо разбираюсь в UNAS, но зато знаю много о других накопителях. Это вызов, документация не очень, поэтому пользователям приходится тестировать и проверять, работает ли это. Если не удается пропинговать UNAS с хоста с большим пакетом, значит, Jumbo Frames не работают или не настроены. Это моя версия, и она была указана в моем тикете в службу поддержки. Спасибо, что нашли время прокомментировать.
 
@stu.w если тебе нужна помощь, пожалуйста, предоставь полную конфигурацию сети, настройки RAID, характеристики дисков и т.д. Случайное переподключение кабелей – это глупо, если ты не посмотрел статистику портов и не выявил проблемы. `dd` на NFS или SMB-шару? Какая ОС у клиента? `dd` с `/dev/zero` или `/dev/urandom`? `fio` — гораздо лучший инструмент для этого. Здесь много постов про UNAS и его проблемы. Ты их читал? Лично я думаю, что он недопроизводительный и не является хорошей заменой чему-либо, кроме базового домашнего использования на данный момент. У меня TrueNAS MiniXL+.
 
Я не особо разбираюсь в UNAS, но кое-что знаю о других устройствах хранения. Если вы не можете пропинговать UNAS с хоста с большим пакетом, значит, Jumbo Frames не работают или не настроены. Попробуйте "ping" с ключом "-s", чтобы установить размер вашего пакета минус 28 бит на заголовок. Пример для пакета ping размером 9000 байт: "ping hostname -s 8972". Linux по умолчанию не фрагментирует пакеты ping, поэтому если ответа нет, значит, пакет не проходит.
 
Я обещаю, что использование Jumbo Frames — это не ваше узкое место. Это так, примерно верно. Я ещё раз провёл тест с MTU установленным в 1500. Производительность заметно возросла, похоже, unas не поддерживает увеличенный MTU, и происходит фрагментация. Был открыт тикет в службу поддержки, может, у них появится решение со временем. Кабели и SFP+ модули были заменены на запасные, но это не помогло. Из магазина Ubiquiti заказано ещё больше Ethernet, SFP+ RJ45 модули и SFP+ DAC кабели. Кто знает, может, все мои кабели, модули и DAC кабели неисправны.

Если у вас нет выделенной изолированной L2-сети только для хранения и вы большая компания, занимающаяся большим количеством работы с данными, то нет причин даже рассматривать их использование. У меня есть выделенная сеть хранения, и я постоянно перемещаю довольно большой объем данных. Самый маленький файл, с которым я работаю над проектом, — 45 МБ, большинство рабочих файлов в несколько гигабайт, многие — в сотни гигабайт, а некоторые — более чем терабайт. Так что прирост, который можно получить при использовании jumbo frames, может накапливаться в течение рабочего дня.

Вы не поделились настройками RAID или спецификациями используемого диска.
Нет, не поделил.

Откуда взялось ваше число 8 Гбит/с?
Я рассчитал скорость на основе спецификаций и количества дисков в RAID-пуле и предоставил округленный результат. Даже если вы считаете это число сомнительным, самый медленный диск, который можно купить, может поддерживать последовательное чтение на скорости 190 МБ/с, что все равно быстрее числа, указанного в моем посте.

Какой инструмент вы используете для тестирования? dd, чтение из файла на общем ресурсе и запись в /dev/null.
Буду рад любым советам, спасибо.

P.S. У продукта конкурента, который заменяется на unas-pro, этой проблемы нет. Проблемы/ы, похоже, ограничиваются unas.
 
Я клянусь тебе, что использование Jumbo Frames — это не твой узкое место. Если у тебя нет отдельной сети уровня L2 только для хранения данных, и ты большая компания, которая много работает с данными, то нет никаких причин даже рассматривать их. Я говорю это, будучи одним из первых сотрудников компании-производителя 10G-коммутаторов и проводившим все тесты и сравнительные испытания со скоростью с компаниями, занимающимися хранением данных. Ты не поделился информацией о RAID-массиве и характеристиками используемого диска. Откуда у тебя взялось число 8Gbit? Какой инструмент ты используешь для тестирования?
Страницы: 1
Читают тему (гостей: 1)