Русский
Русский
English
Статистика
Реклама

Alt-linux

Эльбрус VS Intel. Сравниваем производительность систем хранения Аэродиск Восток и Engine

28.09.2020 06:06:32 | Автор: admin


Всем привет. Мы продолжаем знакомить вас с системой хранения данных Аэродиск ВОСТОК, выполненной на базе российского процессора Эльбрус 8C.


В этой статье мы (как и обещали) детально разберем одну из популярнейших и интереснейших тем, связанной с Эльбрусами, а именно производительность. На тему производительности Эльбруса есть достаточно много спекуляций, причем абсолютно полярных. Пессимисты говорят, что производительность Эльбруса сейчас никакая, и чтобы догнать топовых производителей потребуются десятилетия (т.е. в условиях нынешней реальности никогда). С другой стороны, оптимисты говорят, что уже сейчас Эльбрус 8C показывает хорошие результаты, а в ближайшие пару лет с выходом новых версий процессоров (Эльбрус 16С и 32С) мы сможем догнать и перегнать ведущих мировых производителей процессоров.


Мы в Аэродиске люди практичные, поэтому пошли самым простым и понятным (для нас) путем: протестировать, зафиксировать результаты и только потом делать выводы. В итоге мы провели довольно большое количество тестов и обнаружили ряд особенностей работы Эльбруса 8С архитектуры e2k (в том числе, и приятных) и, конечно же, сравнили это с аналогичными СХД на процессорах Intel Xeon архитектуры amd64.


Кстати, более подробно о тестах, результатах и о будущем развитии СХД на Эльбрусах мы поговорим на нашем очередном вебинаре "ОколоИТ" 15.10.2020 в 15 00. Зарегистрироваться можно по ссылке ниже.


РЕГИСТРАЦИЯ НА ВЕБИНАР


Тестовый стенд


Мы создали два стенда. Оба стенда состоят из сервера с Linux-ом, подключенного через 16G FC-коммутаторы к двум котроллерам СХД, в которой установлено 12 SAS SSD 960 ГБ дисков (11,5 ТБ сырой емкости или 5,7 ТБ полезной емкости, если используем RAID-10).


Схематично стенд выглядит следующим образом.



Стенд 1 e2k (Эльбрус)


Конфигурация оборудования следующая:


  • Linux-сервер (2xIntel Xeon E5-2603 v4 (6 cores, 1,70Ghz), 64 GB DDR4, 2xFC-адаптер 16G 2 порта) 1шт.
  • Коммутатор FC 16 G 2 шт.
  • СХД Аэродиск Восток 2-Э12 (2xЭльбрус 8С (8 cores, 1,20Ghz), 32 GB DDR3, 2xFE FC-adaptor 16G 2 port, 12xSAS SSD 960 GB) 1 шт

Стенд 2 amd64 (Intel)


Для сравнения с аналогичной конфигурации на e2k использовалась похожая конфигурация СХД с похожим процессором по характеристикам на amd64:


  • Linux-сервер (2xIntel Xeon E5-2603 v4 (6 cores, 1,70Ghz), 64 GB DDR4, 2xFC-адаптер 16G 2 порта) 1шт.
  • Коммутатор FC 16 G 2 шт.
  • СХД Aerodisk Engine N2 (2xIntel Xeon E5-2603 v4 (6 cores, 1,70Ghz), 32 GB DDR4, 2xFE FC-adaptor 16G 2 port, 12xSAS SSD 960 GB) 1 шт

Важное замечание: используемые в тесте процессоры Эльбрус 8С поддерживают оперативную память только DDR3, это конечно плохо, но не долго. Эльбрус 8СВ (в наличие его у нас пока нет, но скоро будет) поддерживает DDR4.


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


Для генерации нагрузки мы использовали популярную и проверенную временем программу Flexible IO (FIO).


Обе СХД сконфигурированы согласно нашим же рекомендациям по настройке, исходя из требований к высокой производительности на блочном доступе, поэтому используем дисковые пулы DDP (Dynamic Disk Pool). Чтобы не искажать результаты тестирования, на обеих СХД отключаем, компрессию, дедупликацию и RAM-кэш.


Созданы 8 D-LUN-ов в RAID-10 по 500 ГБ, каждый, суммарный полезный объём составляет 4 ТБ (т.е. примерно 70% от возможной полезной емкости данной конфигурации).


Выполняться будут основные и популярные сценарии использования СХД, в частности:


первые два теста эмулируют работу транзакционной СУБД. В этой группе тестов нам интересны IOPS-ы и задержка.


1) Случайное чтение маленькими блоками 4k
a. Размер блока = 4k
b. Чтение/запись = 100%/0%
c. Количество работ = 8
d. Глубина очереди = 32
e. Характер нагрузки = Full Random


2) Случайная запись маленькими блоками 4k
a. Размер блока = 4k
b. Чтение/запись = 0%/100%
c. Количество работ = 8
d. Глубина очереди = 32
e. Характер нагрузки = Full Random


вторые два теста эмулируют работу аналитической части СУБД. В этой группе тестов нам также интересны IOPS-ы и задержка.


3) Последовательное чтение маленькими блоками 4k
a. Размер блока = 4k
b. Чтение/запись = 100%/0%
c. Количество работ = 8
d. Глубина очереди = 32
e. Характер нагрузки = Sequential


4) Последовательная запись маленькими блоками 4k
a. Размер блока = 4k
b. Чтение/запись = 0%/100%
c. Количество работ = 8
d. Глубина очереди = 32
e. Характер нагрузки = Sequential


третья группа тестов эмулирует работу потокового чтения (пример онлайн трансляции, восстановление резервных копий) и потоковой записи (пример видеонаблюдение, запись резервных копий). В этой группе тестов нам уже интересны не IOPS-ы, а MB/s и также задержка.


5) Последовательное чтение большими блоками 128k
a. Размер блока = 128k
b. Чтение/запись = 0%/100%
c. Количество работ = 8
d. Глубина очереди = 32
e. Характер нагрузки = Sequential


6) Последовательная запись большими блоками 128k
a. Размер блока = 128k
b. Чтение/запись = 0%/100%
c. Количество работ = 8
d. Глубина очереди = 32
e. Характер нагрузки = Sequential


Каждый тест будет длиться один час без учета времени прогрева массива в 7 минут.


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


Результаты тестов сведены в две таблицы.


Эльбрус 8С (СХД Аэродиск Восток 2-Э12)



Intel Xeon E5-2603 v4 (СХД Аэродиск Engine N2)



Результаты получились крайне интересные. В обоих случаях мы хорошо утилизировали процессорные мощности СХД (70-90% утилизации), и при таком раскладе явно бросаются в глаза плюсы и минусы обоих процессоров.


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


Если говорить о случайной нагрузке небольшими блоками, то:


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

В последовательной нагрузке небольшими блоками картина другая:


  • и при чтении, и при записи Intel существенно (в 2 раза) опережает Эльбрус. При этом, если у Эльбруса показатель IOPS ниже чем у Intel, но выглядит достойно (200-300 тысяч), то с задержками явная проблема (они в три раза выше чем у Intel). Вывод, текущая версия Эльбруса 8С очень не любит последовательные нагрузки небольшими блоками. Явно есть над чем работать.

А вот в последовательной нагрузке большими блоками картина прямо противоположная:


  • оба процессора показали примерно равный результат в MB/s, но есть одно НО. Показатели задержек у Эльбруса в 10 (в десять, Карл!!!) раз лучше (т.е. ниже), чем у аналогичного процессора от Intel (0,4/0,5 ms против 5,1/6,5 ms). Вначале мы подумали, что это глюк, поэтому мы перепроверили результаты, сделали повторный тест, но повторный тест показал ту же картину. Это серьезное преимущество Эльбруса (и архитектуры e2k в целом) перед Intel (и, соответственно, архитектуры amd64). Будем надеяться, что этот успех получит дальнейшее развитие.

Есть ещё одна интересная особенность Эльбруса, на которую внимательный читатель может обратить внимание, посмотрев на таблицу. Если взглянуть на разницу показателей чтения и записи у Intel, то во всех тестах чтение опережает запись в среднем примерно на 50%+. Это норма, к которой все (в том числе и мы) привыкли. Если посмотреть на Эльбрус, то показатели записи значительно ближе к показателям чтения, чтение опережает запись, как правило, на 10 30%, не более.


О чем это говорит? О том, что Эльбрус очень любит запись, а это, в свою очередь, говорит о том, что этот процессор будет очень полезен в задачах, где запись явно преобладает над чтением (кто сказал закон Яровой?), что также является несомненным преимуществом архитектуры e2k, и это преимущество нужно развивать.


Выводы и ближайшее будущее


Сравнительные тесты процессоров среднего уровня Эльбрус и Intel для задач хранения данных показали примерно равные и одинаково достойные результаты, при этом каждый процессор показал свои интересные особенности.


Intel сильно превзошел Эльбрус в случайном чтении небольшими блоками, а также в последовательном чтении и записи небольшими блоками.


При случайной записи небольшими блоками оба процессора показывают равные результаты.


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


Кроме того, Эльбрус в отличии от Intel, одинаково хорошо справляется как с нагрузками чтения, так и с нагрузками записи, в то время как у Intel чтение всегда значительно лучше записи.
Исходя из полученных результатов можно сделать вывод о применимости систем хранения данных Аэродиск Восток на процессоре Эльбрус 8С в следующих задачах:


  • информационные системы с преобладанием операций записи;
  • файловый доступ;
  • онлайн-трансляции;
  • видеонаблюдение;
  • резервное копирование;
  • медиа-контент.

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


Данные тесты проводились на ядре Linux для e2k версии 4.19, на текущий момент в бета-тестах (в МЦСТ, в Базальт СПО, а также у нас, в Аэродиске) находится ядро Linux 5.4-e2k, в котором, кроме всего прочего, серьезно переработан планировщик и много оптимизаций под скоростные твердотельные накопители. Также специально для ядер ветки 5.х.х АО МЦСТ выпускает новый компилятор LCC версии 1.25. По предварительным результатам, на том же процессоре Эльбрус 8С, собранное новым компилятором новое же ядро, окружение ядра, системные утилиты и библиотеки и, собственно, ПО Аэродиск ВОСТОК позволит получить ещё более значительный прирост производительности. И это без замены оборудования на том же процессоре и с теми же частотами.


Мы ожидаем выхода версии Аэродиск ВОСТОК на базе ядра 5.4 ближе к концу года, и как только работа над новой версией будет завершена, мы обновим результаты тестирования и также опубликуем их здесь.


Если теперь вернуться к началу статьи и ответить на вопрос, кто же прав: пессимисты, которые говорят, что Эльбрус никакой и никогда не догонит ведущих производителей процессоров, или все-таки оптимисты, которые говорят, что уже почти догнали и скоро перегоним? Если исходить не из стереотипов и религиозных предубеждений, а из реальных тестов, то, однозначно, правы оптимисты.


Эльбрус уже сейчас показывает хорошие результаты, если сравнивать его с процессорами amd64 среднего уровня. До верхних в линейке моделей серверных процессоров Intel или AMD 8-ке Эльбруса, конечно, далеко, но она туда и не целилась, для этого будут выпущены процессоры 16С и 32С. Вот тогда и поговорим.


Мы понимаем, что после этой статьи вопросов про Эльбрус станет ещё больше, поэтому мы решили организовать ещё один онлайн-вебинар ОколоИТ, чтобы в прямом эфире на эти вопросы дать ответы.


В этот раз у нас в гостях будет заместитель генерального директора компании МЦСТ, Константин Трушкин. Записаться на вебинар можно по ссылке ниже.


РЕГИСТРАЦИЯ НА ВЕБИНАР


Всем спасибо, как обычно ждем конструктивной критики и интересных вопросов.

Подробнее..

Нагрузочное тестирование СХД на Эльбрусе на базе нового ядра Линукс версии 5.4

31.05.2021 06:09:55 | Автор: admin


Тестирование СХД Аэродиск Восток на базе процессоров Эльбрус 8С на новом ядре 5.4 показало крайне позитивный результат: 1,4 миллиона IOPS! Пока оптимисты верили и надеялись, а пессимисты снисходительно улыбались, программисты работали писали код. В итоге новая версия ядра Линукс v5.4 для архитектуры Эльбрус позволила в разы улучшить производительность подсистемы ввода-вывода и полностью реализовать процессора Эльбрус 8С/СВ для систем хранения данных.


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


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


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


Общие обновления:


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

Обновления от Аэродиска:


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

Тестовый стенд


Тестирование мы выполняли на том же железе, что и в прошлый раз. Стенд состоит из сервера с Линуксом, подключенного через FC-коммутатор к двум контроллерам СХД Восток, в которой установлено 12 SAS SSD дисков.


Конфигурация оборудования следующая:


  • Linux-сервер (2xIntel Xeon E5-2603 v4 (6 cores, 1,70Ghz), 64 GB DDR4, 2xFC-адаптер 16G 2 порта) 1шт.
  • Коммутатор FC 16G 1 шт.
  • СХД Аэродиск Восток 2-Э12 (2xЭльбрус 8С (8 cores, 1,20Ghz), 32 GB DDR3, 2xFE FC-adaptor 16G 2 port, 12xSAS SSD 960 GB) 1 шт

Ниже схема стенда.



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


Также как и в прошлый раз для нагрузочных тестов мы использовали популярную и проверенную временем программу Flexible IO (FIO).


СХД сконфигурирована исходя из наших рекомендаций к высокой производительности на блочном доступе или просто настройки для ALL-Flash систем. Поэтому используем не менее двух дисковых пулов DDP (Dynamic Disk Pool). Чтобы не бить в одну точку и максимально реализовать вычислительный потенциал платформы создаем несколько LUN-ов в RAID-10 (8 шт. по 500 ГБ каждый).


Все LUN-ы презентуем двум контроллерам (пополам, по 4 каждому), чтобы максимально утилизировать все ресурсы СХД.


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


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


  • 100%_read_4k_sequential
  • 100%_write_4k_sequential

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


  • 100%_read_4k_random
  • 100%_write_4k_random

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


  • 100%_read_128k_sequential
  • 100%_write_128k_sequential

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


Во всех тестах мы, чтобы не искажать результаты тестирования, намеренно отключаем RAM-кэш СХД, который используется для ускорения ввода-вывода, компрессии и дедупликации. Забежим вперед и отдельно скажем про утилизацию оперативной памяти СХД в целом (чтобы к этому вопросу больше не возвращаться). Во всех тестах RAM утилизируется практически одинаково, т.е. слабо, т.к RAM-кэш, дедуп и компрессия отключены. Вся утилизация RAM это внутренние системные операции СХД. Если бы мы включили RAM-кэш, то результаты были бы заметно лучше, но тогда тест был бы не совсем честным. При этом график утилизации оперативки мы для порядка все-равно приводим в отчете ниже.


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


100%_read_4k_sequential

[global]
blocksize=4k
size=80%
direct=1
buffered=0
ioengine=libaio
iodepth=128
group_reporting
rw=read
numjobs=16
runtime=2400
time_based=1
per_job_logs=0
log_avg_msec=30000
write_bw_log=./logs/read-iodepth-128-numjobs-16
write_iops_log=./logs/read-iodepth-128-numjobs-16
write_lat_log=./logs/read-iodepth-128-numjobs-16
[job-1]
filename=/dev/sdj
[job-2]
filename=/dev/sdc
[job-3]
filename=/dev/sdd
[job-4]
filename=/dev/sde
[job-5]
filename=/dev/sdf
[job-6]
filename=/dev/sdg
[job-7]
filename=/dev/sdh
[job-8]
filename=/dev/sdi


100%_write_4k_sequential

[global]
blocksize=4k
size=80%
direct=1
buffered=0
ioengine=libaio
iodepth=128
group_reporting
rw=write
numjobs=16
runtime=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


[job-1]
filename=/dev/sdj
[job-2]
filename=/dev/sdc
[job-3]
filename=/dev/sdd
[job-4]
filename=/dev/sde
[job-5]
filename=/dev/sdf
[job-6]
filename=/dev/sdg
[job-7]
filename=/dev/sdh
[job-8]
filename=/dev/sdi


100%_read_4k_random

[global]
blocksize=4k
size=80%
direct=1
buffered=0
ioengine=libaio
iodepth=64
group_reporting
rw=randread
numjobs=2
runtime=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
[job-1]
filename=/dev/sdc
[job-2]
filename=/dev/sdd
[job-3]
filename=/dev/sde
[job-4]
filename=/dev/sdf
[job-5]
filename=/dev/sdg
[job-6]
filename=/dev/sdh
[job-7]
filename=/dev/sdi
[job-8]
filename=/dev/sdj


100%_write_4k_random

[global]
blocksize=4k
size=80%
direct=1
buffered=0
ioengine=libaio
iodepth=16
group_reporting
rw=randwrite
numjobs=2
runtime=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
[job-1]
filename=/dev/sdc
[job-2]
filename=/dev/sdd
[job-3]
filename=/dev/sde
[job-4]
filename=/dev/sdf
[job-5]
filename=/dev/sdg
[job-6]
filename=/dev/sdh
[job-7]
filename=/dev/sdi
[job-8]
filename=/dev/sdj


100%_read_128k_sequential

[global]
blocksize=128k
size=80%
direct=1
buffered=0
ioengine=libaio
iodepth=128
group_reporting
rw=read
numjobs=16
runtime=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
[job-1]
filename=/dev/sdj
[job-2]
filename=/dev/sdc
[job-3]
filename=/dev/sdd
[job-4]
filename=/dev/sde
[job-5]
filename=/dev/sdf
[job-6]
filename=/dev/sdg
[job-7]
filename=/dev/sdh
[job-8]
filename=/dev/sdi


100%_write128k_sequential

[global]
blocksize=128k
size=80%
direct=1
buffered=0
ioengine=libaio
iodepth=16
group_reporting
rw=write
numjobs=2
runtime=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
[job-1]
filename=/dev/sdj
[job-2]
filename=/dev/sdc
[job-3]
filename=/dev/sdd
[job-4]
filename=/dev/sde
[job-5]
filename=/dev/sdf
[job-6]
filename=/dev/sdg
[job-7]
filename=/dev/sdh
[job-8]


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


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


100%_read_4k_sequential
График загрузки CPU СХД и RAM СХД


Ввод-вывод СХД, IOPS и latency


100%_write_4k_sequential
График загрузки CPU СХД и RAM СХД


Ввод-вывод СХД, IOPS и latency


Результат:


Результаты теста с использованием последовательного характера нагрузки небольшими блоками 4k нас впечатлили, получилось !1,4 миллиона! IOPS на чтение и 700k на запись. Если сравнивать это с предыдущим нашим тестом на ядре 4,19 (371k и 233k IOPS), то это скачек в четыре раза при том, что железо мы не меняли.


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


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


100%_read_4k_random
График загрузки CPU СХД и RAM СХД


Ввод-вывод СХД, IOPS и latency


100%_write_4k_random
График загрузки CPU СХД и RAM СХД


Ввод-вывод СХД, IOPS и latency


Результат:


Показатели случайной нагрузки маленькими блоками, характерной для транзакционных СУБД остались практически без изменений по сравнению с прошлым тестом. СХД Восток на Эльбрусе вполне нормально справляется с подобными задачами, выдавая 118k IOPS на чтение и 84k IOPS на запись при довольно высокой утилизации CPU.


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


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


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


100%_read_128k_sequential
График загрузки CPU СХД и RAM СХД


Ввод-вывод СХД, IOPS и latency


100%_write_128k_sequential
График загрузки CPU СХД и RAM СХД


Ввод-вывод СХД, IOPS и latency


Результат:


Ещё полгода назад СХД Восток на базе процессоров Эльбрус показала отличный результат в тесте последовательной нагрузки большими блоками, что актуально для видеонаблюдения или трансляций. Особой фишкой Эльбруса были ультранизкие задержки при работе с большими блоками (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


Улучшение в 5.4 зеленые, ухудшения 5.4 оранжевые


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


Улучшение в 5.4 зеленые, ухудшения в 5.4 оранжевые


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


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


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


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


В конце этого 21-ого года мы ожидаем новый процессор Эльбрус 16С, который, кроме того что будет намного быстрее, ещё будет поддерживать аппаратную виртуализацию, а это значит что у нас в России наконец-то появится полностью отечественные не только СХД, но и системы виртуализации, и гиперконвергентные системы (кто сказал АИСТ и vAIR?))).


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


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

Подробнее..

Категории

Последние комментарии

  • Имя: Макс
    24.08.2022 | 11:28
    Я разраб в IT компании, работаю на арбитражную команду. Мы работаем с приламы и сайтами, при работе замечаются постоянные баны и лаги. Пацаны посоветовали сервис по анализу исходного кода,https://app Подробнее..
  • Имя: 9055410337
    20.08.2022 | 17:41
    поможем пишите в телеграм Подробнее..
  • Имя: sabbat
    17.08.2022 | 20:42
    Охренеть.. это просто шикарная статья, феноменально круто. Большое спасибо за разбор! Надеюсь как-нибудь с тобой связаться для обсуждений чего-либо) Подробнее..
  • Имя: Мария
    09.08.2022 | 14:44
    Добрый день. Если обладаете такой информацией, то подскажите, пожалуйста, где можно найти много-много материала по Yggdrasil и его уязвимостях для написания диплома? Благодарю. Подробнее..
© 2006-2024, personeltest.ru