Webzilla
Компания
57,10
рейтинг
25 сентября 2014 в 15:48

Разное → SSD + raid0 — не всё так просто

Вступление


Коллеги с соседнего отдела (UCDN) обратились с довольно интересной и неожиданной проблемой: при тестировании raid0 на большом числе SSD, производительность менялась вот таким вот печальным образом:

По оси X — число дисков в массиве, по оси Y — мегабайтов в секунду.

Я начал изучать проблему. Первичный диагноз был простой — аппаратный рейд не справился с большим числом 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())

Представим теперь, что у дисков запись произошла за такое время (в милисекундах):
Диск 1 Диск 2 Диск 3 Диск 4 Диск 5 Диск 6 Диск 7 Диск 8
4.1 2.2 1.9 1.4 1.0 9.7 5.4 8.6

Вопрос: за какое время произойдёт запись блока в 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 несколькими SSD. Если же мы отнормируем цифры по IOPS'ам (охохо), то есть добьёмся от HDD тех же попугаев, что от SSD, то цифры станут, внезапно, другими — массив из большого числа HDD будет сильно обгонять массив из нескольких SSD по скорости записи.

Другое дело, что крупный массив из HDD — это уже экстрим другого рода, и там ждут сюрпризы из-за общего использования шины, производительности HBA и особенностей поведения бэкплейнов.

А raid1/5/6?


Легко понять, что для всех этих массивов проблема с ожиданием «самого медленного» сохраняется, и даже слегка усиливается (то есть проблема возникает при меньшем размере блока и меньшей интенсивности нагрузки).

Заключение


Админское: Не люблю LSI. При обнаружении каких-либо нареканий в работе дисков при участии LSI в системе отладку следует начинать с сравнения поведения разных версий дравйера mpt2sas. Это как раз тот случай, когда смена версии может влиять на производительность и стабильность самым драматичным образом.

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

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

Особое внимание стоит обратить на конфигурации, в которых часть или все диски подключаются по сети с неравномерной задержкой, такая конфигурация вызовет значительно большие затруднения и деградацию, чем локальные диски.
Автор: @amarao
Webzilla
рейтинг 57,10
Компания прекратила активность на сайте

Комментарии (88)

  • +3
    С этой точки зрения, становится очевидно, что важно выбирать правильные SSD, такие у которых задержка плавает по минимуму. Мне нравится как тестируют драйвы на StorageReview — выкладывают графики средней задержки, максимальной и стандартного отклонения для шестичасовых прогонов нескольких разных тестов — сразу становится видно, какая фигня даже некоторые «энтерпрайз» ССД.
    • 0
      Как с любыми сложными устройствами, под разные задачи важны разные параметры. В ряде задач, например, скорость записи вообще не важна, а важна минимальная latency на чтение. Кому-то (обычно, мне) важны sustained IOPS'ы, а деградацию от постоянной крупноблочной записи я считаю граничным и не особо интересным случаем.

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

      А большая часть поста же вообще о том, как кривые драйвера hba могут драматично влиять на производительность устройства.
      • 0
        а какие из дисков SAS (не SSD) можете посоветовать для минимального seek time?
        задача — множество случайного чтения маленькими пакетами (по 2-4к, случайно разбросанные по всему диску)
        • 0
          Весь вопрос — бюджет. Если с ним хорошо — 910ые интелы, или если у них что есть новее из этой линейки. В принципе, с случайным чтением хорошо у любых приличных SSD (разница будет 30к VS 100k IOPS).
          • +1
            я про НЕ ssd говорю. то есть про HDD на SAS (то есть server-level), но с минимальным максимальным seek'ом.
            • 0
              Разве сейчас есть что-то в продаже, что можно ставить в сервера, кроме hitachi типа HUS156060VLS600?
              Хочешь еще более низкий seek — используй от диска только первые 20% емкости.
              • 0
                ну например диски в 300гб меня вполне устраивают объёма, но желательно минимальный сик. выбор по $/time разумеется :)
                • 0
                  Я не совсем понимаю, между чем и чем ты пытаешься выбрать? Кроме hitachi брать то нечего.
                  А уменьшить seek ты можешь только искусственно — отрезав 20-30% от диски и используя только их (ну и купив больший объем, очевидно).
                  • 0
                    ну например те же гнусмасы ST3300657SS
                    • 0
                      Гнусмасы? Может все же сигейты?
                      Открывай www.nix.ru/price/price_list.html?section=hdd_all, выбирай 15k rpm — 5 винтов на выбор, при этом seagate меньше кеша и больше стоят. Выбора нет.
                      • 0
                        HUS156030VLS600 = Seek Time (read, ms, typical) 3.4
                        ST3300657SS = Average Seek Time (read/write ms): 3.4 / 3.9
                        по сути одна фигня. на кеш его мне пофиг, но хитачи выглядят лучше.

                        а ограничивать объём не вариант — надо поймать не просто кусок диска, но еще и нужную область блинов. а то заремапит — и всё равно сики пойдут громадные
                        • 0
                          > а ограничивать объём не вариант — надо поймать не просто кусок диска, но еще и нужную область блинов
                          еще как вариант. как раз где-то 20-25% объема это будет самое начало всех блинов.

                          > а то заремапит — и всё равно сики пойдут громадные
                          ремапы это уже нештатный режим работы. больше шансов, что его выбьет вообще из массива.
            • 0
              У дисков одного класса разница в пределах погрешности.
  • +2
    Года четыре назад столкнулся с этой темой, но видно воз и ныне там.
    У современных SSD слишком много магии внутри, так-что задержка операций может рандомно возникать, очевидно это сервисные операции самих SSD. Производители позаботились о том, что бы для отдельно взятого диска такие припадки случались не часто, но для массива…

    Вангую появление специализированных «ТУПЫХ» SSD, только выгодно ли это производителям.
    • +2
      Вопрос в том, как долго эти «Тупые SSD» протянут, ведь ресурс все же ниже, а массив должен быть отказоустойчивым.
      • +2
        RAID0 может смело быть низконадёжным, если будет высокопроизводительным.

        А делать культурный housekeeping можно и в софте. И, возможно, много более эффективно, т.к. ОС знает, что метаданные, а что данные файлов.
        • 0
          Бухгалтерия, энивей, рада не будет. Тут уже вопрос в том, готова ли организация платить за постоянную смену «тупых» SSD в массиве в угоду скорости, или готова подвинуться и перекатиться на более надежные HDD
          • +8
            Обычно в тот момент, когда о таких конфигурациях идёт речь, мнение бухгалтерии не учитывается, потому что есть бюджет IT-отдела, за который CTO/CIO отчитывается перед CEO/советом директоров/стейкхолдерами.

            Так как любые диски вылетают с некоторым рейтом, дальше вопрос исключительно математики — менять их всё равно придётся с какой-то частотой (обычно несколько в неделю, несколько в день, в зависимости от размера инсталляции). И «умные они», «тупые» — всё равно будут дохнуть.
      • +1
        Тогда не «тупые» нужны, а более приспособленные к raid. Которые будут сообщать контроллеру, дескать «хозяин, пора техобслуживание провести!». Когда контроллер даст добро, то сразу все диски в массиве сделают это одновременно, замедлив только одну(две, десять) операцию.
        • +2
          Это не техобслуживание, а housekeep'ing. И такого уровня взаимодействия современные sas/sata не предусматривают. В свете нарастающего конфликта между потребностями fast storage и старого блочного стека, я думаю, никто уже не будет «немного чинить SCSI». Его полностью утилизируют, заменив на быстрые носители. В принципе, в Ядре начали опять шебуршать на inplace execution, в этом случае носитель находится прямо в адресном пространстве процессора и обращение идёт минуя любую переферию (HBA), примерно как к памяти видеокарты. В этом случае меняются буквально все фундаментальные допущения и предположения об архитектуре persistent devices — и хаускипинг — малая толика из них.

          Если же говорить про меньший хайэнд — как бы они там «не договаривались», если носитель не может выдержать рейт, который требуется для задачи, то будут лаги (то есть рост latency). А уж софт с одной стороны шины их делает, или софт с другой стороны шины — на выходе особой разницы не будет.
  • +2
    «Вот график линейного чтения с одной SSD. » — График без подписи к осям это безобразие. И зачем там столько нулей у килобит? Нельзя у шкалы написать 1000KB/s и урбрать нули?
    • +6
      Извините, оно всё полуавтоматическое в генерации. Когда я понял, что об этом надо писать — большая часть raw-данных была уже утрачена — я по письмам и постам в корпоративную вики выковыривал графики.
  • +5
    Настройте в контроллере политику записи, чтобы разрешала кеширование (я бы рекомендовал ещё доставить туда батарейку, если её нет) — и проблема будет решена.
    • +1
      Многие ssd практически игнорируют управление writeback'ом. Интелы точно уважают, корсары/edge — точно игнорируют. А у hba нет никакого кеша, нет батарейки и быть не может, потому что это HBA, а не рейд-контроллер. С рейд-контроллера вся история началась — он просто не вытягивал нагрузку.

      WB-кеш на рейд-контроллере может улучшать производительность случайной записи, но это, скорее, для шпинделей. В условиях большой многопоточной записи нет никакого смысла в кешах — они будут вымыты в течение долей секунды с момента начала нагрузки.
      • +1
        Я, видимо, недостаточно полно выразил свою мысль, раз кто-то мог предположить, что речь идет от том, игнорируют или нет ssd управление кешированием, или про hba, который никакого кеша не имеет (и батарейки соотв). Позвольте исправиться.

        Рекомендация касается рейд-контроллера, обычно они имеет кеш-память объемом порядка 0.5-2ГБ. Политика записи для новосозданных томов по умолчанию консервативно-безопасная, т.е. кеширования записи нет. Отсюда и проблема с ожиданием винта с самым большим латенси. Но это кеширование можно (и нужно) активировать. При скоростях записи порядка нескольких сотен МБ в секунду кеша контроллера хватит на несколько секунд — что на порядки больше как среднего, так и максимального латенси для ssd. Так что можно ожидать, что рейд-контроллер будет использовать пропускную способность каждого винта по максимуму, раз у него будет данных для него на несколько тысяч операций записи.

        Кстати, кеширование записи средствами рейд-контроллера должно увеличить пропускную способность записи, даже если raid-0 будет создан средствами mdadm — можете проверить и убедиться в этом даже на текущей конфигурации, если том у Вас сейчас работает через mdadm (придется hba заменить на рейд-контроллер, разумеется, и не забыть активировать кеш на запись для каждого экспортируемого ssd).
    • +3
      Батарейка и политки там были по-умолчанию. К сожалению это особо не помогло.
  • 0
    Ещё нужно выравнивать на 4к начало раздела.
    • +1
      Выравнивать кого? Разделы? Современные линуксы таблицы разделов давно начинают со второго мегабайта (полностью пропуская первый) — это даёт выравнивание по куче степеней двойки.

      В этих экспериментах я просто не использовал таблицы разделов, то есть рейд начинался с нулевого сектора.
    • 0
      а SSD это не пофиг-ли?
      • 0
        Очень даже не пофик: просадка скорости + увеличение износа.
  • 0
    Видел на каких-то новых SSD этого года ровные графики latency. Модель уже не припомню.
  • 0
    Это с кешем на запись?
    • 0
      На таких тестах это не играет никакой роли. Любой кеш на запись имеет смысл, когда входящий поток меньше исходящего (в бэкстор) и можно выиграть за счёт его реорганизации или удаления повторяющихся записей. Когда идёт длительная запись большими кусками нечего ни «повторять», ни оптимизировать — надо идти и писать, что сказали.
      • +2
        А ещё можно ответить ОС, что данные записаны, как только они окажутся в кеше контроллера (а не винта). ОС начнет писать следующий кусок данных, это будет происходить со скоростью освобождения места в кеше контроллера. А контроллер тем временем будет сохранять данные из своего кеша на все винты, по максимуму используя их пропускную способность на запись, т.е. устраняя зависимость от блуждания максимального латенси диска.
        • 0
          Если кеш забит — то отвечать «угу», пока кеш не освободится для приёма данных, нельзя. А это, фактически, та же скорость среды. Когда данные льются быстрее, чем «бэк-часть» может их писать, никакое кеширование не поможет для sustained performance. А не sustained, то есть bursts, это совсем другой тип нагрузки.
          • 0
            Кеш будет освобождаться по мере записи данных на винты, причем не важно, на какой из винтов будут записаны данные. Это значит, что как только самые быстрые 8 винтов примут свои 128КБ — будет освобождено 1М кеша. Не дожидаясь медленных винтов — т.е. кеш освобождается с темпом максимальной текущей скорости записи, а не минимальной.
            • 0
              Так, я запутался в схеме. Предположим, у нас в начальный момент времени все буферы полностью заняты. Каждый диск может писать со скоростью от 100 до 200 Мб в секунду, скорость записи в кеш не ограничена. Допустим, для удобства рассмотрения, запись идёт 100 или 200 МБ ровно, блоками по 100Мб. Буффер 1000 Мб.

              Итак,

              секунда 0: буфер 1000, рейд хочет писать, но не может.

              Дальше?
              • +1
                Будет проще объяснить, если принять, что запись будет идти блоками по 1М, каждый блок будет писаться либо 10мс (100МБ/с) либо 100мс (10МБ/с). В буффере 1000МБ, в рейде 10 винтов.

                Контроллер отправляет на 10 винтов по 1МБ. Через 10мс 9 винтов записали свой 1МБ, а один винт пишет. Освободилось 9МБ. Контроллер отправил на свободные 9 винтов ещё по 1МБ — через 10мс они все записали, а десятый винт все ещё пишет предыдущий 1МБ — освободилось ещё 9МБ. Цикл повторяется — итого через 100мс десятый винт наконец записал свой 1МБ, а остальные винты записали к этому времени 10МБ — всего записано 91МБ за 100мс. Среднюю скорость записи посчитаете уже самостоятельно? ))
                • 0
                  Я всегда считал что в raid данные распределяются равномерно между дисками.
                  Из вашего сценария получается, что если данные поступают в кэш быстрее чем диск с самой большой задержкой способен записывать ваш кэш заполнится очередью для десятого и остальные девять будут простаивать. что как бы равносильно отсутствию кэша

                  Если же я ошибаюсь и контроллер пишит на диски со статусом `свободная касса`, то самый медленный диск будет самый пустой, не лучше ли удалить его из массива чтоб не создавал пробок или заменить на более шустрый?
                  • 0
                    Разумеется, данные распределяются равномерно между дисками. Контроллер не выбирает, на какой из них писать данные — это делает файловая система.

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

                    Если же какой-то диск будет тупить постоянно, то контроллер и правда забьет свой кеш данными только для него, и общая производительность записи сравняется с скоростью записи такого диска. Но это уже клинический случай, такой диск нужно менять.
                  • 0
                    Там всё сложнее. Во-первых, контроллер не может выбирать, на какие из дисков писать. Надо писать туда, куда сказали (точнее, куда попадает по математике).
                    Во-вторых, контроллер может иметь очередь, и в этой очереди команды, за вычетом барьеров и флашей, можно выполнять в любой последовательности, то есть умный контроллер может объединять запросы, переупорядочивать их, выкидывать «перезаписываемые» операции и т.д.

                    В третьих устройства под контроллером имеют свою очередь и умный контроллер может следить за ней, например, резервируя часть под разные потоки данных (например, запись и чтение).

                    В четвёртых, в ОС есть разные алгоритмы работы с очередью ОС. Например, CFQ старается сделать так, чтобы среди всех отправленных запросов, все приложения получили свою долю, даже если кто-то активный, а кто-то не очень. Альтернативным CFQ является deadline, который стремится к тому, чтобы ни один из запросов не валялся в очереди слишком долго. Любимым для high performance является noop, который делает ничего, а просто передаёт запросы ниже — это снижает latency.
      • 0
        Вроде в этом конкретном случае кэш мог бы помочь — можно начинать новую операцию не дожидаясь пока самый медленое устройство закончит прошлую. В результате производительнось должна приблизится к средней.
        • 0
          Как он может его начинать, если кеш забит? Если не забит, то он быстро принимает данные, и ему тут же подсовывают следующие. И так до тех пор, пока кеш не забит. Поскольку кеш быстрее самого устройства, он будет отвечать «да» быстрее, чем скидывать данные — до тех пор, пока не забьётся.
      • 0
        Я так понимаю, когда говорят в этом топике про кэш, имеют ввиду кэш между md и устройством. Кэшей потребуется по числу дисков, каждый из них будет говорить md, что данные на этот диск записаны, чем в свою очередь сгладит неровность работы каждого диска. Производительность должна приближаться к сумме средних, а не сумме минимумов.
        • +1
          Это не HBA режим. В HBA-режиме нет никаких кешей, и не контроллера, как активного участника процесса.

          Вообще, можно включать writeback на самих устройствах (и это даёт ошеломительную разницу на консьюмерских SSD — у меня на ноуте intel'овское чудо 500ой серии показывает 280 IOPS без writeback и 50к+ — с writeback'ом, и вопрос там не только в том, что «сначала насосались, потом пишем», главное — консолидация мелкого IO кратно уменьшающая количество «больших» операций).

          В случае, когда пишут много, все кеши оказываются заполнены. Легко понять почему: предположим, у нас скорость втока — 400Мб/с, скорость «вытока» — от 200 до 300. Буффер — 200 Мб.

          Мы начинаем писать на рейд — сначала все всасывают с микроскопической latency 200Мб и начинают её писать. За несколько секунд буффера заполняются. Все и у всех. У кого-то буфер заполняется раньше, у кого-то позже, но заполняется он у всех. И с этого момента мы сталкиваемся с тем, что запись в буфер возможна только если там освободилось место. Частично это проблему простоя снимает, но у SSD проблема отличается от 'seek time' для HDD. У hdd, если за счёт буферизации можно делать seek после ответа «хорошо» на запрос записи, то скорость растёт. У SSD если в промежутках между приёмами данных продолжать писать, то для housekeep'инга не остаётся времени, и в какой-то момент начинает страдать запись. В буфер ли, напрямую.

          Буфер помогает — но не с latency. Более того, по очевидным причинам буфер, наборот, усиливает разброс latency (от «записали в буфер, вернули ок» до «стоп, буфер заполнен, пытаемся хоть что-то скинуть, а там хаускипинг, который настаивает, что он важнее, так что ждём его»). Разброс усиливается из-за того, что худший вариант у всех тот же самый, а лучший — лучше у writeback.
  • 0
    А если брать СХД от таких больших вендоров IBM, HP, DELL и прочие, то какие они методы применяют когда пишут «данная СХД работает с SSD дисками»? Может они что то придумали для уменьшения данного эффекта? Или они думают только об износе?
    • +2
      Что конкретный продавец подразумевает в этот момент — возможно, не знает даже он. Может, у них раньше контроллер сыпался при виде RPM=1, а теперь перестал. А может, они перестали кешировать данные на чтение и оптимизируют запись для облегчения жизни SSD?

      Наиболее практичный ответ: SSD внесли в HCL и всевозможные чёрно-белые списки внутри контроллера.
  • 0
    Задержку в реальной работе можно в разы, а то и на порядок, уменьшить зная особенность работы контроллера SSD диска. Контроллеру для максимальной производительности необходимо свободное место на диске. Оптимально оставлять 25% диска не размеченой.
    По ссылке можно увидеть графики для сравнения www.anandtech.com/show/6489/playing-with-op

    Таким образом производительность всего рейда в рабочих условиях увеличится значительно.
    • +3
      Известный вопрос с underprovisioning'ом, но не для случая крупноблочной записи. Суть underprovision'инга в том, что когда пишут мелкие блоки, надо вместо них писать большие — читаются данные, записываются. Чем больше пустого места, тем проще найти пустой целый блок.

      Когда же SSD просят записать большой блок (больше, чем внутренний блок в SSD), то никакого выигрыша это не должно давать, просто потому, что нечего «переносить» — надо целиком перезаписывать.
      • 0
        То есть для мелких операций записи это реально помогающий метод — размечать не весь диск?
        Я знал, что надо оставлять свободное место, но не знал, что это не связано с партициями
        • 0
          Разделы к этому не имеют никакого отношения. Надо понимать, что free space с точки зрения контроллера диска и файловой системы — две большие разницы. Для контроллера free space — это то, куда пока что никто не писал. Ни разу. Если записали и удалили — всё равно область с данными. Таким образом, чем больше свободного места с точки зрения контроллера, тем ему легче. Но с точки зрения контроллера fs, на которую хоть раз полностью записали все блоки, а потом переформатировали заново — всё равно полностью заполнена.

          Единственные два исключения: операция TRIM и secure erase. TRIM делают многие файловые системы для ненужных данных, secure erase делается всегда руками и целиком для диска.

          Когда говорят про практический underprovision'ing, то речь идёт о том, чтобы с самого начала ограничить используемое место на диске и никогда туда не писать. Иногда делают это через lba limits (то есть диск рапортует про меньшее место, чем есть), иногда через ограничение размера раздела, иногда — посредством правильного использования FS с поддержкой trim.

          Эффект сильно разнится от контроллера к контроллеру, но из практических соображений иметь ФС, на которой меньше 10% свободного места — плохо. Так что обычная ФС (ext3, ext4) отлично справится с задачей underprovision'инга.
  • 0
    Спасибо, познавательно.
    Скажите, чем вас не устроил iostat, раз вы решили написать blktop?
    • +2
      Надо понимать ситуацию, в которой писались ifstop и iostat — под сотню и больше дисков и сетевых интерфейсов клиентов, сложные маппинги lvm/raid/multipath… Если вы на такой простыне запустите iostat, то получите простыню на три экрана. Причём нагрузка скачет, то есть однократный вывод не достаточен, надо посмотреть некоторое время.

      Фактически, вещи, которых не хватает в iostat
      — цвета (чтобы сразу знать, куда смотреть)
      — показа io_time (atop его показывает, но не для всех блочных устройств в системе)
      — реального времени (показа нагрузки не «вообще», а за последние секунды)

      разница такая же, как между ps и top. Одно другое не заменяет, а дополняет.
  • –2
    В сущности, RAID — мертвая технология.

    Можно сколь-угодно натягивать кожу и колоть ботокс, но сути не меняет.

    У нас в Nutanix нет никаких проблем с SSD дисками при том что используется тот-же линукс и LSI контроллер.

    Но мы не используем рейд, вообще. Ни программный ни аппаратный.

    LSI при этом работает прекрасно, один из лучших аппаратных контроллеров. Так что автору статьи тут скорее подходит — «вы не любите кошек? просто не умеете их готовить» :)

    Нет рейда -> нет указанных в статье проблем.

    • 0
      Во-первых, nutanix ровно так же получит бобо от кривых LSI'ных дров, как и все остальные. (или есть супертехнология превращения кривых дров в некривые?).

      Во-вторых, после исключения драйверов и хардварного рейда мы получили 10% разницы между теорией и практикой. Вы говорите, что у вас «нет рейда -> нет проблем», а какая производительность на 6-10 SSD'шках в страйпе/без реданданси будет? А в сравнении с конфигом на одной SSD'шке? Тестировали? Покажите? (я не уверен, что кто-то заметит 10% просто так; я заметил, потому что следил за цифрами по мере устранения боттлнеков).
  • +1
    Подозреваю на аппаратных рейдах под SSD, проблема решается большим кэшем.

    Думаю что скоро будет развитие технологий отложенной записи в оперативную память, например сейчас это реализовано в SSD гражданской версии PlexTurbo от Plextor или в Самсунге EVO.
    Если подобные решения перейдут в enterprise, то такая схема решит подобную проблему и на софтовых рэйдах
    • 0
      Проблема большого кеша решается записью данных в объёме, существенно большем, чем кеш.
  • 0
    Надо, всего-то, сделать асинхронный raid-контроллер, который не будет ждать пока операцию выполнит каждый диск, чтобы начать новую.
    • 0
      Как вы представляете себе асинхронный raid0? В случае падения одного диска вы как можно быстрее должны сообщить системе, о том, что массив развалился. Если не согласны, можете сразу в /dev/null писать :)
      • +1
      • 0
        В чем проблема?

        Если у нас есть 2 операции на запись. Что мешает запустить 2ю пока первая не завершилась? А системе об успехе операции записи мы сообщаем когда она фактически завершилась. Нет. Не вижу проблем.
        • 0
          Если в контроллере включен кеш на запись — он тогда так и будет работать: См. выше Т.е. все уже придумано до нас.
          Если кеша нет, то в момент сбоя ссд встанет ридонли (правильная смерть). А вы начали следующую операцию. Или уже даже следующую за ней…
          • 0
            Иии?

            Возьмем за правило операция может быть закончена только после того как будут закончены все операции начатые до начала операции. Все. Никаких проблем. В случае сбоя, винт переходит в ридонли и все начатые операции завершаются с ошибкой. Никаких проблем.
            • 0
              В контексте raid0 пофигу, в контексте обычных рейдов это называется «очередь» и на реальных данных работает ограниченно, потому что в какой-то момент ОС говорит «стоп, запиши СНАЧАЛА это». И вся очередь начинает писаться. А софт ждёт, пока допишется. Получается внезапный и очень неприятный всплеск latency.

              Нельзя сделать очередь подлиннее так, чтобы в ней ждали поменьше (любому человеку в супермаркете это очевидно).
              • –2
                Ну значит еще и ОСки надо переработать.
                • 0
                  Не надо никого перерабатывать. Есть такая программа: eatmydata.

                  Делаете eatmydata mysqld — и ваш mysql работает в -цать раз быстрее.
  • 0
    Хм, простите, а увеличение chunk не дает увеличения скорости? Какой он у вас сейчас кстати?
    Ведь если куски данных которые пишет каждый диск будут достаточно большими, чтобы зацепить несколько областей, то на каждом диске будет усреднение. И вы тогда получите не сложение минимумов, а сложение «средних».
    И ещё. Вы не любите LSI. А что вам нравится больше? Какой HBA на много портов выбрать-то?
    • 0
      Я пробовал менять chunk, при росте chunk'а скорость падает.

      Из всех HBA я не имею ни малейшего нарекания только к intel'ам. Точнее, у них есть проблема с потолком производительности, но зато никаких глюков я от них никогда не видел. К сожалению, 6 портов максимум, sata, и только в составе чипсета.

      Подавал надежды adaptec'овский HBA (не путать с рейдами) — но когда я его видел (через пол-года после анонса) он был ещё сырой-сырой-сырой. В том смысле, что драйверов в апстриме не было, только сырцы на сайте самого адаптека. Надеюсь, они это поправили.
      • 0
        Хм. А почему эта скорость падает? Чем то это должно объяснятся? Или она падает на мелких операциях? И на столько сильно, что приращение на последовательных уже становится не так важным?

        Ну про интел — это понятно. Хотя, может кто-то сумеет из чипсета сделать съёмную плату и тогда будет 6*n. Но пока 6 — это предел, и он очень печальный. Я пока до 10 догоняю через ASMedia 1061 (1062). Но там всего 2 порта. Про Marvel у меня вообще печальный опыт: avryabov.livejournal.com/5056.html
        А в планах собрать хранилище на 15 HDD, но тут похоже ничего лучше LSI нету. И это меня огорчает…
        • 0
          Падает она на ожидании внезапного протупления — то есть если один диск протупил, остальные ждут.

          Насчёт marvel спасибо, буду знать.
          • 0
            Дык внезапные протупления и на меньших чунках бывают.
            Или получается так, что на меньших чунках вероятность протупления одного из дисков далеко не 100%, а сильно меньше?
            Но даже тут не должно быть снижения производительности.
            Просто моя идея была в том, чтобы протупления дисков друг на друга накладывались. Чтобы диски тупили параллельно.
            Сейчас у тебя один тупит — а другие уже отработали. И быстрые ждут тормоза. Если чунк большой — то каждому диску достается большой кусок, и он с высокой вероятностью будет и тупить, и быстро работать, просто на разных местах. Один в начале тормознет, второй в конце, третий в середине, но к финишу все приедут примерно вместе.
            Возможные замедления в такой схеме могут быть с нескольких сторон:
            1. на мелких операциях, которые раньше раскладывались на несколько дисков, а сейчас упираются в производительность меньшего количества.
            2. буфера в системе/приложении которые пишут инфу на диск, не большие, и при большом чунке их тупо не хватает, чтобы нагрузить все диски параллельно, и из восьми работает например 4, а следующие четыре начнут писать только после того, как эти закончат свою работу, когда система отдаст приложению ответ — с этими данными я закончила, давай следующие.
            Первое — это принципиальное понижение производительности, и тут ничего нельзя сделать. А второе — потенциально излечимо.
            Или я какой-то другой механизм снижения производительности пропустил?
            • 0
              Больший чанк — большее время «тупления» на конкретном блоке. Модели можно делать разные, у меня по мере роста размера чанка падала суммарная скорость.
  • +1
    Админское:
    Я теперь тоже не люблю LSI.
    Купил 9750-4i, обнаружил, что если включить кэширование записи — скорость возрастает (ожидаемо).
    А вот если включить кэширование записи с батарейной защитой — скорость уменьшается.

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

    прошивка и последняя и не последняя, один чёрт.
    • 0
      Неприятная вещь. А они никаких объяснений этой логике не дают? Как вариант, если батарея есть, но не включена на уровне контроллера, тормоза есть? Если из, скажем, 4 дисков на контроллере с батареей собрать два зеркала, в первом включить кеширование, во втором — нет, то тормоза в обоих есть?
      • 0
        Всем давно известно, что кэш на запись при использовании SSD надо отключать.
        • 0
          У меня обычные SAS-hdd
      • 0
        Объяснение было «а, окей, так и должно работать»
        На вопрос — а зачем тогда вообще нужен кэш записи, не ответили.

        Оно так себя ведёт вне зависимости от количества дисков, от включение-выключения кэша на чтение, от того, есть ли второй том без кэша записи.

        А вот второй том (который без кэша) работает нормально.

        При чём — обратите внимание — с включённым кэшем записи и батареей — оно работает МЕДЛЕННЕЕ.
        При чём заметно, чуть ли не на 30-50% (уже точно не помню цифру, но это не пара процентов)

        перетыкал диски в Adaptec-овский контроллер — всё хоккей
        • 0
          Скорее всего брак или глючки прошивки/драйверов.

          Я тоже пободался с поддержкой одного вендора, когда в пришедшем сервере RAID-контроллер выдавал жуткую latency. Вначале проблему признавать отказывались, написав, что это нормально:
          Мы воспроизвели ситуацию (RAID10 на этих шести дисках, запись нулями при создании): средние задержки около 850 ms, больше 1000 не поднимается. Потом добавили два SSD в RAID0: задержки около 400 ms.
  • 0
    Скажите, а HBA с SSD-specific мелочами, вроде TRIM, как себя ведут? Грубо, передают то, что ОСь отдала в сторону диска(-ов), и эту проблему перекладывает на плечи ОСи, или сам о том помнит и сам же делает? А плата RAID в этом смысле как себя вела?

    Я к тому, что не может ли оно влиять (по крайней мере, в реально жизни, а не при записи байтов от начала к концу) на поведение дисков?

    • 0
      HBA трим даёт делать, новые версии linux-raid дают делать trim, хардварные рейды в режиме JBOD обычно не дают.
    • 0
  • 0
    Пожалуйста уберите линии из графиков. Какой в них смысл? Вы измеряете значения дискретной величины, подразумевать непрерывность нет смысла. Более того, на самом первом графике характер кривой меняется на величине 5,5 дисков. Что это значит? Что вызывает такой эффект?
    • 0
      Не могу убрать. Большая часть данных — пост-фактум, то есть как срендерили на момент написания, так и есть. Для части данных у меня хотя бы raw-данные остались — для части только картинки из переписки.
  • 0
    Не далее чем сегодня задался вопросом исследования производительности RAID-0. Началось все с того что при создании индексов в большой (300Gb) базе данных. Загрузка легла на плечи одного SSD. %util в iostat -x показывал 6% 100% 6%. При этом, это не было похоже, на загрузку из-за высокой latency диска. Т.к. чтение с загруженного диска было 200мб/cек, а с двух оставшихся по 16мб/сек. Chunk size 512k. Как такое получилось пока у меня в голове не укладывается. Возможно у топик стартера или собравшихся будут идеи по этому поводу? Я пока пройдусь тестами по дискам массива и по массиву в собранном состоянии. Чтобы кроме цифр iostat были и графики.
    • 0
      Прогнал тесты и нашел причину. т.к. для работы raid использовалось 3 диска 128, 120 и 256 (собирали из того что было :)). большая часть объема raid-0 успешно использовала все 3 диска, и только 128 GB в хвосте работали напрямую только с большим диском. потому и проседала скорость когда диск заполнялся почти полностью. Для более опытных коллег, может это и было очевидно. Ну а я сегодня узнал что-то новое. :)
  • 0
    Прошу прощения за некропостинг, возникло интересное предположение, и очень захотелось его проверить. Если, конечно, автор статьи ещё помнит и мониторит ответы на свои статьи.

    Вопрос следующий. Не была ли запись на SSD, график скорости которой показан на первой картинке, первой записью по всей поляне после покупки SSD? Ступенька могла быть связана с формированием транслятора «на лету». А при следующем замере, уже с обновлённым драйвером, транслятор уже был сформирован, и поэтому график стал ровным.
    • 0
      Вроде бы таких штук на других SSD не было. Хотя точно сказать не могу, мы уже на другие модели давно перешли.

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

Самое читаемое Разное