ВступлениеКоллеги с соседнего отдела (UCDN) обратились с достаточно занимательной и неожиданной проблемой: при тестировании raid0 на солидном числе SSD, производительность изменялась вот таким вот печальным образом:По оси X — число дисков в массиве, по оси Y — мегабайтов в секунду.
Смотрите кроме этого: Asus Zenbook NX500 поступит в продажу в третьем квартале

На выставке Computex 2014 компания Asus представила NX500 — новую флагманскую модель в линейке ультрабуков Zenbook. Отличительной изюминкой NX500 есть наличие 15,6-дюймого дисплея формата Ultra HD со особой пленкой на базе квантовых точек QDEF производства компании 3M, снабжающей точность цветопередачи. В аппаратную конфигурацию NX500 входит процессор Intel Core i7 четвертого поколения, трудящийся в сочетании с видеоплатой NVIDIA GeForce GTX 850M.

Zenbook NX500 — это первый продукт Asus, в котором употребляется дисплей Asus Visual Master.

Я начал изучать проблему. Первичный диагноз был несложной — аппаратный рейд не справился с солидным числом SSD и упёрся в собственный личный потолок по производительности.По окончании того, как аппаратный рейд выбросили и на его место поставили HBA, а диски собрали в raid0 посредством linux-raid (его довольно часто именуют ‘mdadm’ по заглавию утилиты командной строки), обстановка улучшилась. Но не прошла всецело -цифры возросли, но всё ещё были ниже рассчётных.

Наряду с этим главным параметром были не IOPS’ы, а многопоточная линейная запись (другими словами громадные куски данных, записываемых в случайные места).Обстановка для меня была необыкновенной — я ни при каких обстоятельствах не гонялся за чистым bandwidth рейдов. IOPS’ы — отечественное всё. А тут — нужно многомногомного в секунду и побольше.Адские графикиЯ начал с определения baseline, другими словами производительности единичного диска. Делал я это, скорее, для очистки совести. Вот график линейного чтения с одной SSD.

Заметив итог я реально взвился. По причине того, что это сильно напоминало ухищрения, на каковые идут производители недорогих USB-флешек. Они помещают стремительную память в районы размещения FAT (таблицы) в FAT32 (файловой совокупности) и более медленную — в район хранения данных.

Это разрешает чуть-чуть победить по производительности при работе с небольшими операциями с метаданными, наряду с этим предполагая, что пользователи, копирующие громадные файлы во-первых готовы подождать, а во вторых сами операции будут происходить большими блоками. Подробнее про это душераздирающее явление: lwn.net/Articles/428584/Я верил в том, что определил причину и корень всех неприятностей и уже готовил язвительное послание (см. подписи на картине), растолковывающее, какое унылое некачественное оборудование класса «удобрение» выяснилось на тесте, и многие другие слова, каковые лучше не повторять.Не смотря на то, что меня смутила версия ядра на стенде — 3.2.

По собственному прошлому опыту зная прискорбные изюминки LSI, меняющие в драйверах (mpt2sas) от версии к версии практически всё, я поразмыслил, «а что если»?Мало предыстории. mpt2sas — драйвер LSI для HBA. Живёт поразительно активной судьбой, начав с версии с версии v00.100.11.15 через версии 01.100.0x.00 дойдя аж до версии 16.100.00.00 (Примечательно, что свидетельствует цифра «100»?).

За это время драйвер отличился перестановкой имён букв дисков при обновлении минорной версии ядра, отличающемся от аносируемого биосом порядком дисков, падениями на «неожиданных» конфигурациях LUN’ов, на таймаутах бэкплейна, на неожиданном числе дисков, логгинг неточностей в dmesg со скоростью нескончаемого цикла в самом ядре (де-факто это эквивалент зависания совокупности) и тому подобные радостные вещи. Обновились, запустили тест. И данный «внезапно» произошёл. Вот как выглядит тот же график на 3.14.

А ведь я чуть-чуть было не забраковал невинные SSD’шки.По окончании того, как производительность дисков стабилизировалась, был совершён второй тест: на все диски запустили свободные тесты параллельно. Цель была несложна — проверить, нет ли бутылочного горлышка где-то на шине либо HBA. Производительность дисков была в полной мере приличной, «затыка» по шине не было.

Главная задача была решена. Но, график производительности всё-таки отличался. Не очень сильно, но очевидно с намёком на хуже чем линейную скорость записи.Из-за чего запись так себя ведёт по мере повышения числа дисков в массиве?

График (в начале статьи) сильно напоминал график производительности многопоточных приложений по мере роста числа потоков, на каковые в большинстве случаев показывают программисты и Intel’овцы, в то время, когда говорят о проблемах у обоюдных блокировок тредов…На протяжении теста в blktop наблюдалось что-то необычное: часть дисков загружена в потолок, часть практически простаивает. Причём загружены в потолок те, кто показывает низкую производительность, а «стремительные» диски простаивают.

Более того, диски время от времени изменяются местами — другими словами раньше загруженный на 100% диск внезапно показывает меньшую загрузку и большую скорость, и напротив, диск, что был загружен на 50%, внезапно оказывается загружен на 100% и наряду с этим показывает меньшую скорость. Из-за чего?В этот самый момент до меня дошло.raid0 зависит от latency нехорошего из дисковЕсли мы пишем большое количество данных, то запись в большинстве случаев идёт громадными кусками. Эти куски разделяются на меньшие куски драйвером raid0, что записывает их в один момент на все диски из raid0.

За счёт этого мы приобретаем N-кратное повышение производительности. (В raid0 на N дисков).Но давайте разглядим запись подробнее…Допустим, у нас raid применяет chunk’и размером в 512k. В массиве 8 дисков. Приложение желает записать большое количество данных, и мы пишем на raid кусками по 4Мб.Сейчас смотрите за руками:

1. raid0 приобретает запрос на запись, дробит эти на 8 кусков по 512кб любой
2. raid0 отправляет (параллельно) 8 запросов на 8 устройств по записи 512кб (любой собственное)
3. raid0 ожидает подтверждение от всех 8 устройств о завершении записи
4. raid0 отвечает приложению «записал» (другими словами возвращает управление из вызова write())

Представим сейчас, что у дисков запись случилась за такое время (в милисекундах):

Вопрос: за какое время случится запись блока в 4Мб на данный массив? Ответ: за 9.7 мс. Вопрос: какая будет сейчас утилизация у диска №4? Ответ: порядка 10%. А у диска №6? 100%.

Увидим, для примера я выбрал самые экстремальные значения из лога операций, но и при меньшем расхождении неприятность будет сберигаться. Сравните записи и график чтения (привожу ту же картину ещё раз):Видите, как неровно гуляет запись в сравнении с чтением?У SSD дисков latency на запись весьма неровная. Связано это с их внутренним устройством (в то время, когда за раз записывается блок громадного размера, при необходимости, перемещая и перенося эти с места на место).

Чем больше данный блок, тем посильнее пики latency (другими словами сиюминутные провалы в производительности). У простых магнитных дисков графики совсем другие — они напоминают ровную линию фактически без отклонений. При линейного последовательного IO эта линия проходит высоко, при постоянного случайного IO — неизменно низко, но, главное — неизменно.

Latency у твёрдых дисков предсказуема, latency у SSD — нет. Увидим, это свойство имеется у всех дисков. У самых дорогих latency оказывается смещена (или весьма скоро, или очень скоро) — но разнобой всё равняется сохраняется.При аналогичных колебаниях latency производительность у SSD, в среднем, хорошая, но в отдельные моменты времени запись может занять чуть больше, чем в второе время.

У тестируемых дисков она падала сейчас до позорных размеров порядка 50Мб/с (что ниже, чем линейная запись у современных HDD раза в два).В то время, когда на устройство запросы идут стопкой и независимо, это не воздействует. Ну да, один запрос выполнился скоро, второй медлительно, в среднем всё прекрасно.Но в случае если запись зависит от всех дисков в массиве? В этом случае, любой «тормознувший» диск тормозит всю операцию полностью.

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

Розовая линия — предсказания, базирующиеся на средней производительности дисков, светло синий — фактические результаты.При 7 дисков различия составили около 10%.Простое математическое симулирование (с данными по latency настоящего диска для обстановки множества дисков в массиве) разрешило угадать, что по мере повышения числа дисков деградация может дойти до 20-25%.В отличие от замены HBA либо версии драйвера, в этом случае ничего значительно поменять уже не было возможности, и данные к сведению.Что лучше — HDD либо SSD?Сходу сообщу: нехорошее ожидание от SSD оказывается лучше, чем постоянное от HDD (в случае если раздалось через чур сложно: SSD лучше, чем HDD).Однако массив из 20-30 HDD — это естественно. 30 SSD в raid0 приведут к у гиков и приступ печёночной колики у денежного отдела.

Другими словами в большинстве случаев сравнивают множество HDD c несколькими HDD. В случае если же мы отнормируем цифры по IOPS’ам (охохо), другими словами добьёмся от HDD тех же попугаев, что от SSD, то цифры станут, неожиданно, вторыми — массив из солидного числа HDD будет очень сильно обгонять массив из нескольких SSD по скорости записи.Однако большой массив из HDD — это уже экстрим другого рода, и в том месте ожидают сюрпризы из-за неспециализированного применения шины, производительности HBA и изюминок поведения бэкплейнов.А raid1/5/6?Легко понять, что для всех этих массивов неприятность с ожиданием «самого медленного» сохраняется, а также легко улучшается (другими словами неприятность появляется при меньшем меньшей интенсивности и размере блока нагрузки).ЗаключениеАдминское: Не обожаю LSI.

При обнаружении каких-либо нареканий в работе дисков при участии LSI в совокупности отладку направляться затевать с сравнения поведения различных предположений дравйера mpt2sas. Это именно тот случай, в то время, когда смена версии может оказывать влияние на стабильность и производительность самым драматичным образом. Отвлечённое: При планировании высоконагруженных совокупностей с применением SSD в raid0 направляться учитывать, что чем больше в массиве SSD, тем посильнее делается эффект от неравномерной latency.

По мере роста числа устройств в raid0 производительность устройства начинает стремиться к произведению числа устройств на минимальную производительность дисков (а не среднюю, как хотелось бы ожидать). Советы: при с подобным типом нагрузки направляться стараться выбирать устройства с мельчайшим разбросом по latency на запись, по возможности применять устройства с большей ёмкостью (для уменьшения числа устройств). Особенное внимание стоит обратить на конфигурации, в которых часть либо все диски подключаются по сети с неравномерной задержкой, такая конфигурация позовёт намного большие затруднения и деградацию, чем локальные диски.

Случайная статья:

• Qualcomm snapdragon 820 вдвое энергоэффективнее, чем snapdragon 810
• Lg g4 официально представлен в россии

СОЕДИНЯЕМ 4 ДИСКА SSD В RAID 0 ИЗМЕРЯЕМ СКОРОСТЬ

Похожие статьи:

• Не все так просто: как рестораны фотографируют еду

  Ранее в отечественном блоге мы говорили о том, какие конкретно дизайн-техники употребляются для меню в ресторанах. В комментариях кое-какие читатели…

• Видеозахват на все случаи жизни

  Здравствуй, направляться. Сейчас поболтаем о достаточно несложной теме, которая, однако, время от времени создаёт кое-какие неприятности как…

• Ты помнишь, как всё начиналось…

  В данной статье я попытаюсь поведать о том, как же на свет показался аудиотракт смартфона Highscreen Boost 3, что был представлен в сентябре и поступил в…