Нагрузочное Тестирование Схд На Эльбрусе На Базе Нового Ядра Linux Версии 5.4

Тестирование СХД «Аэродиск Восток» на базе процессоров «Эльбрус 8С» на новом ядре 5.4 показало крайне положительный результат: 1,4 миллиона IOPS! Пока оптимисты верили и надеялись, а пессимисты снисходительно улыбались, программисты работали — писали код. В результате новая версия ядра Linux v5.4 для архитектуры Эlbrus позволила существенно повысить производительность подсистемы ввода-вывода и полностью реализовать процессор Эlbrus 8C/SV для систем хранения данных.

По этому чудесному случаю мы в Аэродиске, предварительно обновив боевую версию встроенного в СХД ВОСТОК боевого Alt-Linux до ядра 5.4, повторно провели нагрузочное тестирование СХД, которое мы опубликовали полгода назад. Предыдущий отчет можно найти здесь связь .

Были проведены новые тесты на долгожданном ядре Linux для e2k версии 5.4, появившемся в начале 2021 года, за что хотелось бы сказать огромное спасибо командам разработчиков МЦСТ, Базальт СПО, а также Михаилу Шигорин лично.

В ядре 5.4 много изменений, но нас интересуют только основные изменения с точки зрения хранилища, и их можно разделить на следующие группы: Общие обновления:

• планировщик ввода-вывода был переработан, что позволяет лучше распараллеливать операции ввода-вывода между дисками;
• множество небольших оптимизаций для высокоскоростных твердотельных накопителей;
• и самое главное изменение — новый компилятор от МЦСТ (LCC версия 1.25).

• обновлен целевой драйвер, который позволяет лучше распараллеливать ввод-вывод между ядрами процессора;
• обновление логики комбинации ядро-диск для систем на Эlbrus.

Испытательный стенд

Стенд представляет собой Linux-сервер, подключенный через FC-коммутатор к двум контроллерам СХД «Восток», на которых установлено 12 SSD-накопителей SAS. Конфигурация оборудования следующая:

• Linux-сервер (2xIntel Xeon E5-2603 v4 (6 ядер, 1,70 ГГц), 64 ГБ DDR4, 2xFC-адаптера 16G 2 порта) – 1 шт.
• Переключатель FC 16G – 1 шт.
• Система хранения данных Аэродиск Восток 2-?12 (2xLbrus 8C (8 ядер, 1,20Ghz), 32 ГБ DDR3, 2xFE FC-переходник 16G 2 порта, 12xSAS SSD 960 ГБ) - 1 шт.

Методика тестирования

Система хранения настроена на основе наших рекомендаций по высокой производительности на блочном доступе или просто настроек для ALL-Flash систем.

Поэтому мы используем как минимум два дисковых пула DDP (Dynamic Disk Pool).

Чтобы не попасть в одну точку и максимально использовать вычислительный потенциал платформы, мы создаем несколько LUN в RAID-10 (8 штук по 500 ГБ каждый).

Все LUNы подносим на два контроллера (пополам, по 4 штуки), чтобы максимально использовать все ресурсы хранилища.

В ходе тестирования будут реализованы следующие популярные сценарии использования СХД, в частности: Последовательная загрузка небольшими блоками 4к

• 100%_read_4k_sequential
• 100%_write_4k_sequential

• 100%_read_4k_random
• 100%_write_4k_random

• 100%_read_128k_sequential
• 100%_write_128k_sequential

Во всех тестах, чтобы не искажать результаты тестирования, мы намеренно отключаем кэш оперативной памяти хранилища, который используется для ускорения ввода-вывода, сжатия и дедупликации.

Забежим вперед и отдельно поговорим об использовании оперативной памяти СХД в целом (чтобы не возвращаться к этому вопросу еще раз).

Во всех тестах оперативная память используется практически одинаково, то есть слабо, поскольку кэш ОЗУ, дедупликация и сжатие отключены.

Все использование оперативной памяти — это внутренние системные операции системы хранения.

Если бы мы включили кэш ОЗУ, результаты были бы заметно лучше, но тогда тест был бы не совсем честным.

При этом для порядка мы все же приводим график утилизации оперативной памяти в отчете ниже.

Кроме того, по опыту публикации предыдущей статьи о производительности Эlbrus и по многочисленным просьбам работников, мы также выкладываем подробные конфиги FIO. 100%_read_4k_sequential [Глобальный] размер блока = 4 КБ размер=80% прямой = 1 буферизовано = 0 ioengine = libaio ioглубина = 128 group_reporting rw=прочитать число заданий = 16 время выполнения = 2400 time_based=1 per_job_logs=0 log_avg_msec=30000 write_bw_log=.

/logs/read-iolength-128-numjobs-16 write_iops_log=.

/logs/read-iolength-128-numjobs-16 write_lat_log=.

/logs/read-iolength-128-numjobs-16 [задание-1] имя файла =/dev/sdj [задание-2] имя файла =/dev/sdc [задание-3] имя файла =/dev/sdd [задание-4] имя файла=/dev/sde [задание-5] имя файла =/dev/sdf [задание-6] имя файла =/dev/sdg [задание-7] имя файла =/dev/sdh [задание-8] имя файла =/dev/sdi 100%_write_4k_sequential [Глобальный] размер блока = 4 КБ размер=80% прямой = 1 буферизовано = 0 ioengine=libaio ioглубина = 128 group_reporting rw=запись число заданий = 16 время выполнения = 2400 time_based=1 write_bw_log=.

/logs/4k-seq-write.results write_iops_log=.

/logs/4k-seq-write.results write_lat_log=.

/logs/4k-seq-write.results [задание-1] имя файла =/dev/sdj [задание-2] имя файла =/dev/sdc [задание-3] имя файла =/dev/sdd [задание-4] имя файла=/dev/sde [задание-5] имя файла =/dev/sdf [задание-6] имя файла =/dev/sdg [задание-7] имя файла =/dev/sdh [задание-8] имя файла =/dev/sdi 100%_read_4k_random [Глобальный] размер блока = 4 КБ размер=80% прямой = 1 буферизовано = 0 ioengine=libaio ioглубина = 64 group_reporting rw=randread число заданий = 2 время выполнения = 2400 time_based=1 per_job_logs=0 log_avg_msec=30000 write_bw_log=.

/logs/4k-rand-read.results write_iops_log=.

/logs/4k-rand-read.results write_lat_log=.

/logs/4k-rand-read.results [задание-1] имя файла =/dev/sdc [задание-2] имя файла =/dev/sdd [задание-3] имя файла=/dev/sde [задание-4] имя файла =/dev/sdf [задание-5] имя файла =/dev/sdg [задание-6] имя файла =/dev/sdh [задание-7] имя файла =/dev/sdi [задание-8] имя файла =/dev/sdj 100%_write_4k_random [Глобальный] размер блока = 4 КБ размер=80% прямой = 1 буферизовано = 0 ioengine=libaio ioглубина=16 group_reporting rw = рандрайт число заданий = 2 время выполнения = 2400 time_based=1 per_job_logs=0 log_avg_msec=30000 write_bw_log=.

/logs/4k-rand-write.results write_iops_log=.

/logs/4k-rand-write.results write_lat_log=.

/logs/4k-rand-write.results [задание-1] имя файла =/dev/sdc [задание-2] имя файла =/dev/sdd [задание-3] имя файла=/dev/sde [задание-4] имя файла =/dev/sdf [задание-5] имя файла =/dev/sdg [задание-6] имя файла =/dev/sdh [задание-7] имя файла =/dev/sdi [задание-8] имя файла =/dev/sdj 100%_read_128k_sequential [Глобальный] размер блока = 128 тыс.

размер=80% прямой = 1 буферизовано = 0 ioengine=libaio ioглубина = 128 group_reporting rw=прочитать число заданий = 16 время выполнения = 2400 time_based=1 per_job_logs=0 log_avg_msec=30000 write_bw_log=.

/logs/128k-seq-read.results write_iops_log=.

/logs/128k-seq-read.results write_lat_log=.

/logs/128k-seq-read.results [задание-1] имя файла =/dev/sdj [задание-2] имя файла =/dev/sdc [задание-3] имя файла =/dev/sdd [задание-4] имя файла=/dev/sde [задание-5] имя файла =/dev/sdf [задание-6] имя файла =/dev/sdg [задание-7] имя файла =/dev/sdh [задание-8] имя файла =/dev/sdi 100%_write128k_sequential [Глобальный] размер блока = 128 тыс.

размер=80% прямой = 1 буферизовано = 0 ioengine=libaio ioглубина=16 group_reporting rw=запись число заданий = 2 время выполнения = 2400 time_based=1 per_job_logs=0 log_avg_msec=30000 write_bw_log=.

/logs/128k-seq-write.results write_iops_log=.

/logs/128k-seq-write.results write_lat_log=.

/logs/128k-seq-write.results [задание-1] имя файла =/dev/sdj [задание-2] имя файла =/dev/sdc [задание-3] имя файла =/dev/sdd [задание-4] имя файла=/dev/sde [задание-5] имя файла =/dev/sdf [задание-6] имя файла =/dev/sdg [задание-7] имя файла =/dev/sdh [задание-8]

Результаты теста

Последовательная загрузка небольшими блоками 4к

Если сравнить это с нашим предыдущим тестом на ядре 4.19 (371к и 233к IOPS), то это скачок четыре раза несмотря на то, что железо мы не меняли.

Также отметим довольно небольшую загрузку процессора, она примерно на 20% ниже, чем в предыдущем тесте (69/71% против 76/92%).

Задержки остались на том же уровне, что и полгода назад, это не значит, что мы собираемся с этим мириться, это значит, что мы еще будем над этим работать.

В конце статьи будет итоговая сравнительная таблица с тестом полугодовой давности на ядре 4.19.

Случайная загрузка небольшими блоками 4к

С такими задачами СХД «Восток» на Lbrus справляется вполне неплохо, выдавая 118k IOPS на чтение и 84k IOPS на запись при достаточно высокой загрузке процессора.

Заметим, что для Эlbrus, в отличие от других процессоров, работа в режиме постоянной нагрузки, близкой к 100%, является нормальной ситуацией (он для этого и создан).

Мы это проверили, оставив СХД Восток с процессором, загруженным на 95%, на несколько дней и результат был следующий: 1) процессор холодный; 2) процессор и система в целом работали в штатном режиме.

Поэтому к высокому уровню утилизации процессоров «Фильбрус» следует относиться спокойно.

Также из предыдущего ядра сохранилась приятная возможность.

Если посмотреть на задержки при случайной загрузке небольшими блоками, то обращает на себя внимание то, что задержки записи ниже задержек чтения (3 мс против 8 мс), когда мы все к этому привыкли, а должно быть наоборот .

Эlbrus, с точки зрения случайного характера нагрузки, все же больше любит писать, чем читать, что, несомненно, является отличным преимуществом, которым грех было бы не воспользоваться.

Последовательная загрузка большими блоками 128к

Особенностью ЭLbrus была сверхнизкая задержка при работе с большими блоками (0,4-0,5 мс против 5 - 6 мс у аналогичного процессора архитектуры x-86).

При чтении данных большими блоками это преимущество не только закреплялось, но и развивалось.

Максимальная скорость на новом ядре увеличена вдвое (5,7 ГБ/с на ядре 5.4 против 2,6 ГБ/с на ядре 4.19) при задержке 0,3 мс! Также загрузка процессора в этом тесте выглядит лучше (52% при 5,4 против 75% при 4,19).

А вот с записью все не так радужно.

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

Они находятся на уровне 11 мс (а были 0,5 мс), что в целом неплохо, потому что.

Примерно такой же уровень задержки мы видим в этом тесте на процессорах других архитектур.

Так или иначе, это наше домашнее задание, над которым мы будем работать.

Однако положительный момент все же есть.

Как и в других тестах, существенно снижается загрузка процессора (74% против 95%).

Итоговые результаты тестирования АРОДИСК ВОСТОК на базе процессоров Эльбрус 8С, ядро 5.4

Для сравнения приведены результаты тестирования АРОДИСК ВОСТОК на базе процессоров Эльбрус 8С, ядро 4.19. Улучшение в 5,4 – зеленый, ухудшение в 5,4 – оранжевый.

Прогресс виден невооруженным глазом! Новая версия ядра 5.4 для архитектуры «Эльбрус» позволила выжать практический максимум из совершенно нового процессора «Эльбрус 8С» (выпуск 2016 года).

На данный момент даже самые ярые пессимисты уже не посмеют назвать процессор LBRUS медленным, ведь полтора миллиона IOPS — это очень много.

Мы в очередной раз убедились в отличной производительности систем хранения в среде, где преобладает последовательная нагрузка, а это аналитические СУБД, онлайн-трансляции, видеонаблюдение, обработка больших данных и т. д. Кроме того, Эlbrus хорошо работает при случайных нагрузках записи, демонстрируя минимальные задержки, что важно для классических транзакционных СУБД.

Конечно, есть еще над чем работать (те же задержки при записи больших потоков), но за последние полгода команда МЦСТ проделала титаническую работу, и она дала видимый результат, что не может не радовать.

В конце 21-го года мы ожидаем новый процессор lbrus 16C, который помимо того, что будет значительно быстрее, еще и будет поддерживать аппаратную виртуализацию, а это значит, что в России у нас наконец-то появятся полностью отечественные не только СХД.

, но и системы виртуализации, и гиперконвергентные системы (кто сказал AIST и vAIR?))).

Кстати о птицах! В течение этой недели мы определимся с датами проведения следующего технического вебинара «ОколоИТ» о нашей системе виртуализации AIST и гиперконвергентной системе vAIR, ссылка на регистрацию появится в этой статье (следите за обновлениями), а также в нашей телеграмма чат .

Ну и, конечно же, не можем не напомнить вам о бесплатных курсах по системам Aerodisk, которые вы можете подпишите здесь .

На этой позитивной ноте мы завершаем очередную статью о Эlbrus. Традиционно ждем каверзных вопросов, конструктивных дискуссий и предложений.

#Русское оборудование #Альт-linux #alt-linux

• Клаус, Карл Карлович (Карл-Эрнст)

  19 Oct, 24

• Дублирование Cd И Dvd – Новое Лицо Технологии

  19 Oct, 24

• Маршалл, Альфред

  19 Oct, 24

• Наведение Порядка В Розетке

  19 Oct, 24

• Набор Для Сборки Самобалансирующегося Робота Edumip На Базе Beaglebone Blue. Распаковка И Сборка. Часть 1

  19 Oct, 24

• Новая Динамическая Защита От Эксплойтов Для Остановки Атак На Самой Ранней Стадии Эксплуатации Уязвимостей.

  19 Oct, 24

• «Мегафон» Заказал Систему Хранения «Купол» Для Хранения Трафика По Закону Яровой

  19 Oct, 24

• Платформа Для Создания Приложений С Открытым Исходным Кодом И Менеджер Пакетов Для Windows

  19 Oct, 24

• Разработчики Смогут Отвечать На Комментарии В Google Play

  19 Oct, 24

• Microsoft И Apple Выпустят Веб-Версии Своих «Офисных» Продуктов!

  19 Oct, 24