Комментарии 89
НЛО прилетело и опубликовало эту надпись здесь
Как с любыми сложными устройствами, под разные задачи важны разные параметры. В ряде задач, например, скорость записи вообще не важна, а важна минимальная latency на чтение. Кому-то (обычно, мне) важны sustained IOPS'ы, а деградацию от постоянной крупноблочной записи я считаю граничным и не особо интересным случаем.
Я думаю, если сильно покопаться, то можно будет найти разных лидеров в разных областях.
А большая часть поста же вообще о том, как кривые драйвера hba могут драматично влиять на производительность устройства.
Я думаю, если сильно покопаться, то можно будет найти разных лидеров в разных областях.
А большая часть поста же вообще о том, как кривые драйвера hba могут драматично влиять на производительность устройства.
а какие из дисков SAS (не SSD) можете посоветовать для минимального seek time?
задача — множество случайного чтения маленькими пакетами (по 2-4к, случайно разбросанные по всему диску)
задача — множество случайного чтения маленькими пакетами (по 2-4к, случайно разбросанные по всему диску)
Весь вопрос — бюджет. Если с ним хорошо — 910ые интелы, или если у них что есть новее из этой линейки. В принципе, с случайным чтением хорошо у любых приличных SSD (разница будет 30к VS 100k IOPS).
я про НЕ ssd говорю. то есть про HDD на SAS (то есть server-level), но с минимальным максимальным seek'ом.
Разве сейчас есть что-то в продаже, что можно ставить в сервера, кроме hitachi типа HUS156060VLS600?
Хочешь еще более низкий seek — используй от диска только первые 20% емкости.
Хочешь еще более низкий seek — используй от диска только первые 20% емкости.
ну например диски в 300гб меня вполне устраивают объёма, но желательно минимальный сик. выбор по $/time разумеется :)
Я не совсем понимаю, между чем и чем ты пытаешься выбрать? Кроме hitachi брать то нечего.
А уменьшить seek ты можешь только искусственно — отрезав 20-30% от диски и используя только их (ну и купив больший объем, очевидно).
А уменьшить seek ты можешь только искусственно — отрезав 20-30% от диски и используя только их (ну и купив больший объем, очевидно).
ну например те же гнусмасы ST3300657SS
Гнусмасы? Может все же сигейты?
Открывай www.nix.ru/price/price_list.html?section=hdd_all, выбирай 15k rpm — 5 винтов на выбор, при этом seagate меньше кеша и больше стоят. Выбора нет.
Открывай www.nix.ru/price/price_list.html?section=hdd_all, выбирай 15k rpm — 5 винтов на выбор, при этом seagate меньше кеша и больше стоят. Выбора нет.
HUS156030VLS600 = Seek Time (read, ms, typical) 3.4
ST3300657SS = Average Seek Time (read/write ms): 3.4 / 3.9
по сути одна фигня. на кеш его мне пофиг, но хитачи выглядят лучше.
а ограничивать объём не вариант — надо поймать не просто кусок диска, но еще и нужную область блинов. а то заремапит — и всё равно сики пойдут громадные
ST3300657SS = Average Seek Time (read/write ms): 3.4 / 3.9
по сути одна фигня. на кеш его мне пофиг, но хитачи выглядят лучше.
а ограничивать объём не вариант — надо поймать не просто кусок диска, но еще и нужную область блинов. а то заремапит — и всё равно сики пойдут громадные
> а ограничивать объём не вариант — надо поймать не просто кусок диска, но еще и нужную область блинов
еще как вариант. как раз где-то 20-25% объема это будет самое начало всех блинов.
> а то заремапит — и всё равно сики пойдут громадные
ремапы это уже нештатный режим работы. больше шансов, что его выбьет вообще из массива.
еще как вариант. как раз где-то 20-25% объема это будет самое начало всех блинов.
> а то заремапит — и всё равно сики пойдут громадные
ремапы это уже нештатный режим работы. больше шансов, что его выбьет вообще из массива.
У дисков одного класса разница в пределах погрешности.
Года четыре назад столкнулся с этой темой, но видно воз и ныне там.
У современных SSD слишком много магии внутри, так-что задержка операций может рандомно возникать, очевидно это сервисные операции самих SSD. Производители позаботились о том, что бы для отдельно взятого диска такие припадки случались не часто, но для массива…
Вангую появление специализированных «ТУПЫХ» SSD, только выгодно ли это производителям.
У современных SSD слишком много магии внутри, так-что задержка операций может рандомно возникать, очевидно это сервисные операции самих SSD. Производители позаботились о том, что бы для отдельно взятого диска такие припадки случались не часто, но для массива…
Вангую появление специализированных «ТУПЫХ» SSD, только выгодно ли это производителям.
Вопрос в том, как долго эти «Тупые SSD» протянут, ведь ресурс все же ниже, а массив должен быть отказоустойчивым.
RAID0 может смело быть низконадёжным, если будет высокопроизводительным.
А делать культурный housekeeping можно и в софте. И, возможно, много более эффективно, т.к. ОС знает, что метаданные, а что данные файлов.
А делать культурный housekeeping можно и в софте. И, возможно, много более эффективно, т.к. ОС знает, что метаданные, а что данные файлов.
Бухгалтерия, энивей, рада не будет. Тут уже вопрос в том, готова ли организация платить за постоянную смену «тупых» SSD в массиве в угоду скорости, или готова подвинуться и перекатиться на более надежные HDD
Обычно в тот момент, когда о таких конфигурациях идёт речь, мнение бухгалтерии не учитывается, потому что есть бюджет IT-отдела, за который CTO/CIO отчитывается перед CEO/советом директоров/стейкхолдерами.
Так как любые диски вылетают с некоторым рейтом, дальше вопрос исключительно математики — менять их всё равно придётся с какой-то частотой (обычно несколько в неделю, несколько в день, в зависимости от размера инсталляции). И «умные они», «тупые» — всё равно будут дохнуть.
Так как любые диски вылетают с некоторым рейтом, дальше вопрос исключительно математики — менять их всё равно придётся с какой-то частотой (обычно несколько в неделю, несколько в день, в зависимости от размера инсталляции). И «умные они», «тупые» — всё равно будут дохнуть.
Тогда не «тупые» нужны, а более приспособленные к raid. Которые будут сообщать контроллеру, дескать «хозяин, пора техобслуживание провести!». Когда контроллер даст добро, то сразу все диски в массиве сделают это одновременно, замедлив только одну(две, десять) операцию.
Это не техобслуживание, а housekeep'ing. И такого уровня взаимодействия современные sas/sata не предусматривают. В свете нарастающего конфликта между потребностями fast storage и старого блочного стека, я думаю, никто уже не будет «немного чинить SCSI». Его полностью утилизируют, заменив на быстрые носители. В принципе, в Ядре начали опять шебуршать на inplace execution, в этом случае носитель находится прямо в адресном пространстве процессора и обращение идёт минуя любую переферию (HBA), примерно как к памяти видеокарты. В этом случае меняются буквально все фундаментальные допущения и предположения об архитектуре persistent devices — и хаускипинг — малая толика из них.
Если же говорить про меньший хайэнд — как бы они там «не договаривались», если носитель не может выдержать рейт, который требуется для задачи, то будут лаги (то есть рост latency). А уж софт с одной стороны шины их делает, или софт с другой стороны шины — на выходе особой разницы не будет.
Если же говорить про меньший хайэнд — как бы они там «не договаривались», если носитель не может выдержать рейт, который требуется для задачи, то будут лаги (то есть рост latency). А уж софт с одной стороны шины их делает, или софт с другой стороны шины — на выходе особой разницы не будет.
«Вот график линейного чтения с одной SSD. » — График без подписи к осям это безобразие. И зачем там столько нулей у килобит? Нельзя у шкалы написать 1000KB/s и урбрать нули?
Настройте в контроллере политику записи, чтобы разрешала кеширование (я бы рекомендовал ещё доставить туда батарейку, если её нет) — и проблема будет решена.
Многие ssd практически игнорируют управление writeback'ом. Интелы точно уважают, корсары/edge — точно игнорируют. А у hba нет никакого кеша, нет батарейки и быть не может, потому что это HBA, а не рейд-контроллер. С рейд-контроллера вся история началась — он просто не вытягивал нагрузку.
WB-кеш на рейд-контроллере может улучшать производительность случайной записи, но это, скорее, для шпинделей. В условиях большой многопоточной записи нет никакого смысла в кешах — они будут вымыты в течение долей секунды с момента начала нагрузки.
WB-кеш на рейд-контроллере может улучшать производительность случайной записи, но это, скорее, для шпинделей. В условиях большой многопоточной записи нет никакого смысла в кешах — они будут вымыты в течение долей секунды с момента начала нагрузки.
Я, видимо, недостаточно полно выразил свою мысль, раз кто-то мог предположить, что речь идет от том, игнорируют или нет ssd управление кешированием, или про hba, который никакого кеша не имеет (и батарейки соотв). Позвольте исправиться.
Рекомендация касается рейд-контроллера, обычно они имеет кеш-память объемом порядка 0.5-2ГБ. Политика записи для новосозданных томов по умолчанию консервативно-безопасная, т.е. кеширования записи нет. Отсюда и проблема с ожиданием винта с самым большим латенси. Но это кеширование можно (и нужно) активировать. При скоростях записи порядка нескольких сотен МБ в секунду кеша контроллера хватит на несколько секунд — что на порядки больше как среднего, так и максимального латенси для ssd. Так что можно ожидать, что рейд-контроллер будет использовать пропускную способность каждого винта по максимуму, раз у него будет данных для него на несколько тысяч операций записи.
Кстати, кеширование записи средствами рейд-контроллера должно увеличить пропускную способность записи, даже если raid-0 будет создан средствами mdadm — можете проверить и убедиться в этом даже на текущей конфигурации, если том у Вас сейчас работает через mdadm (придется hba заменить на рейд-контроллер, разумеется, и не забыть активировать кеш на запись для каждого экспортируемого ssd).
Рекомендация касается рейд-контроллера, обычно они имеет кеш-память объемом порядка 0.5-2ГБ. Политика записи для новосозданных томов по умолчанию консервативно-безопасная, т.е. кеширования записи нет. Отсюда и проблема с ожиданием винта с самым большим латенси. Но это кеширование можно (и нужно) активировать. При скоростях записи порядка нескольких сотен МБ в секунду кеша контроллера хватит на несколько секунд — что на порядки больше как среднего, так и максимального латенси для ssd. Так что можно ожидать, что рейд-контроллер будет использовать пропускную способность каждого винта по максимуму, раз у него будет данных для него на несколько тысяч операций записи.
Кстати, кеширование записи средствами рейд-контроллера должно увеличить пропускную способность записи, даже если raid-0 будет создан средствами mdadm — можете проверить и убедиться в этом даже на текущей конфигурации, если том у Вас сейчас работает через mdadm (придется hba заменить на рейд-контроллер, разумеется, и не забыть активировать кеш на запись для каждого экспортируемого ssd).
Батарейка и политки там были по-умолчанию. К сожалению это особо не помогло.
НЛО прилетело и опубликовало эту надпись здесь
Выравнивать кого? Разделы? Современные линуксы таблицы разделов давно начинают со второго мегабайта (полностью пропуская первый) — это даёт выравнивание по куче степеней двойки.
В этих экспериментах я просто не использовал таблицы разделов, то есть рейд начинался с нулевого сектора.
В этих экспериментах я просто не использовал таблицы разделов, то есть рейд начинался с нулевого сектора.
а SSD это не пофиг-ли?
Видел на каких-то новых SSD этого года ровные графики latency. Модель уже не припомню.
Это с кешем на запись?
На таких тестах это не играет никакой роли. Любой кеш на запись имеет смысл, когда входящий поток меньше исходящего (в бэкстор) и можно выиграть за счёт его реорганизации или удаления повторяющихся записей. Когда идёт длительная запись большими кусками нечего ни «повторять», ни оптимизировать — надо идти и писать, что сказали.
А ещё можно ответить ОС, что данные записаны, как только они окажутся в кеше контроллера (а не винта). ОС начнет писать следующий кусок данных, это будет происходить со скоростью освобождения места в кеше контроллера. А контроллер тем временем будет сохранять данные из своего кеша на все винты, по максимуму используя их пропускную способность на запись, т.е. устраняя зависимость от блуждания максимального латенси диска.
Если кеш забит — то отвечать «угу», пока кеш не освободится для приёма данных, нельзя. А это, фактически, та же скорость среды. Когда данные льются быстрее, чем «бэк-часть» может их писать, никакое кеширование не поможет для sustained performance. А не sustained, то есть bursts, это совсем другой тип нагрузки.
Кеш будет освобождаться по мере записи данных на винты, причем не важно, на какой из винтов будут записаны данные. Это значит, что как только самые быстрые 8 винтов примут свои 128КБ — будет освобождено 1М кеша. Не дожидаясь медленных винтов — т.е. кеш освобождается с темпом максимальной текущей скорости записи, а не минимальной.
Так, я запутался в схеме. Предположим, у нас в начальный момент времени все буферы полностью заняты. Каждый диск может писать со скоростью от 100 до 200 Мб в секунду, скорость записи в кеш не ограничена. Допустим, для удобства рассмотрения, запись идёт 100 или 200 МБ ровно, блоками по 100Мб. Буффер 1000 Мб.
Итак,
секунда 0: буфер 1000, рейд хочет писать, но не может.
Дальше?
Итак,
секунда 0: буфер 1000, рейд хочет писать, но не может.
Дальше?
Будет проще объяснить, если принять, что запись будет идти блоками по 1М, каждый блок будет писаться либо 10мс (100МБ/с) либо 100мс (10МБ/с). В буффере 1000МБ, в рейде 10 винтов.
Контроллер отправляет на 10 винтов по 1МБ. Через 10мс 9 винтов записали свой 1МБ, а один винт пишет. Освободилось 9МБ. Контроллер отправил на свободные 9 винтов ещё по 1МБ — через 10мс они все записали, а десятый винт все ещё пишет предыдущий 1МБ — освободилось ещё 9МБ. Цикл повторяется — итого через 100мс десятый винт наконец записал свой 1МБ, а остальные винты записали к этому времени 10МБ — всего записано 91МБ за 100мс. Среднюю скорость записи посчитаете уже самостоятельно? ))
Контроллер отправляет на 10 винтов по 1МБ. Через 10мс 9 винтов записали свой 1МБ, а один винт пишет. Освободилось 9МБ. Контроллер отправил на свободные 9 винтов ещё по 1МБ — через 10мс они все записали, а десятый винт все ещё пишет предыдущий 1МБ — освободилось ещё 9МБ. Цикл повторяется — итого через 100мс десятый винт наконец записал свой 1МБ, а остальные винты записали к этому времени 10МБ — всего записано 91МБ за 100мс. Среднюю скорость записи посчитаете уже самостоятельно? ))
Я всегда считал что в raid данные распределяются равномерно между дисками.
Из вашего сценария получается, что если данные поступают в кэш быстрее чем диск с самой большой задержкой способен записывать ваш кэш заполнится очередью для десятого и остальные девять будут простаивать. что как бы равносильно отсутствию кэша
Если же я ошибаюсь и контроллер пишит на диски со статусом `свободная касса`, то самый медленный диск будет самый пустой, не лучше ли удалить его из массива чтоб не создавал пробок или заменить на более шустрый?
Из вашего сценария получается, что если данные поступают в кэш быстрее чем диск с самой большой задержкой способен записывать ваш кэш заполнится очередью для десятого и остальные девять будут простаивать. что как бы равносильно отсутствию кэша
Если же я ошибаюсь и контроллер пишит на диски со статусом `свободная касса`, то самый медленный диск будет самый пустой, не лучше ли удалить его из массива чтоб не создавал пробок или заменить на более шустрый?
Разумеется, данные распределяются равномерно между дисками. Контроллер не выбирает, на какой из них писать данные — это делает файловая система.
Контроллер пишет на все диски, для которых у него есть данные на запись. В примере выше показано, что даже если один диск затупит, то остальные диски продолжат запись на полной скорости, освобождая память контроллера под новые данные с высокой полной скоростью. Диск, который затупил, обычно не делает это постоянно, а только изредка, поэтому он потом догонит остальные диски (в моменты когда будут тупить время от времени другие диски).
Если же какой-то диск будет тупить постоянно, то контроллер и правда забьет свой кеш данными только для него, и общая производительность записи сравняется с скоростью записи такого диска. Но это уже клинический случай, такой диск нужно менять.
Контроллер пишет на все диски, для которых у него есть данные на запись. В примере выше показано, что даже если один диск затупит, то остальные диски продолжат запись на полной скорости, освобождая память контроллера под новые данные с высокой полной скоростью. Диск, который затупил, обычно не делает это постоянно, а только изредка, поэтому он потом догонит остальные диски (в моменты когда будут тупить время от времени другие диски).
Если же какой-то диск будет тупить постоянно, то контроллер и правда забьет свой кеш данными только для него, и общая производительность записи сравняется с скоростью записи такого диска. Но это уже клинический случай, такой диск нужно менять.
Там всё сложнее. Во-первых, контроллер не может выбирать, на какие из дисков писать. Надо писать туда, куда сказали (точнее, куда попадает по математике).
Во-вторых, контроллер может иметь очередь, и в этой очереди команды, за вычетом барьеров и флашей, можно выполнять в любой последовательности, то есть умный контроллер может объединять запросы, переупорядочивать их, выкидывать «перезаписываемые» операции и т.д.
В третьих устройства под контроллером имеют свою очередь и умный контроллер может следить за ней, например, резервируя часть под разные потоки данных (например, запись и чтение).
В четвёртых, в ОС есть разные алгоритмы работы с очередью ОС. Например, CFQ старается сделать так, чтобы среди всех отправленных запросов, все приложения получили свою долю, даже если кто-то активный, а кто-то не очень. Альтернативным CFQ является deadline, который стремится к тому, чтобы ни один из запросов не валялся в очереди слишком долго. Любимым для high performance является noop, который делает ничего, а просто передаёт запросы ниже — это снижает latency.
Во-вторых, контроллер может иметь очередь, и в этой очереди команды, за вычетом барьеров и флашей, можно выполнять в любой последовательности, то есть умный контроллер может объединять запросы, переупорядочивать их, выкидывать «перезаписываемые» операции и т.д.
В третьих устройства под контроллером имеют свою очередь и умный контроллер может следить за ней, например, резервируя часть под разные потоки данных (например, запись и чтение).
В четвёртых, в ОС есть разные алгоритмы работы с очередью ОС. Например, CFQ старается сделать так, чтобы среди всех отправленных запросов, все приложения получили свою долю, даже если кто-то активный, а кто-то не очень. Альтернативным CFQ является deadline, который стремится к тому, чтобы ни один из запросов не валялся в очереди слишком долго. Любимым для high performance является noop, который делает ничего, а просто передаёт запросы ниже — это снижает latency.
Вроде в этом конкретном случае кэш мог бы помочь — можно начинать новую операцию не дожидаясь пока самый медленое устройство закончит прошлую. В результате производительнось должна приблизится к средней.
Я так понимаю, когда говорят в этом топике про кэш, имеют ввиду кэш между md и устройством. Кэшей потребуется по числу дисков, каждый из них будет говорить md, что данные на этот диск записаны, чем в свою очередь сгладит неровность работы каждого диска. Производительность должна приближаться к сумме средних, а не сумме минимумов.
Это не 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.
Вообще, можно включать 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.
А если брать СХД от таких больших вендоров IBM, HP, DELL и прочие, то какие они методы применяют когда пишут «данная СХД работает с SSD дисками»? Может они что то придумали для уменьшения данного эффекта? Или они думают только об износе?
Что конкретный продавец подразумевает в этот момент — возможно, не знает даже он. Может, у них раньше контроллер сыпался при виде RPM=1, а теперь перестал. А может, они перестали кешировать данные на чтение и оптимизируют запись для облегчения жизни SSD?
Наиболее практичный ответ: SSD внесли в HCL и всевозможные чёрно-белые списки внутри контроллера.
Наиболее практичный ответ: SSD внесли в HCL и всевозможные чёрно-белые списки внутри контроллера.
Задержку в реальной работе можно в разы, а то и на порядок, уменьшить зная особенность работы контроллера SSD диска. Контроллеру для максимальной производительности необходимо свободное место на диске. Оптимально оставлять 25% диска не размеченой.
По ссылке можно увидеть графики для сравнения www.anandtech.com/show/6489/playing-with-op
Таким образом производительность всего рейда в рабочих условиях увеличится значительно.
По ссылке можно увидеть графики для сравнения www.anandtech.com/show/6489/playing-with-op
Таким образом производительность всего рейда в рабочих условиях увеличится значительно.
Известный вопрос с underprovisioning'ом, но не для случая крупноблочной записи. Суть underprovision'инга в том, что когда пишут мелкие блоки, надо вместо них писать большие — читаются данные, записываются. Чем больше пустого места, тем проще найти пустой целый блок.
Когда же SSD просят записать большой блок (больше, чем внутренний блок в SSD), то никакого выигрыша это не должно давать, просто потому, что нечего «переносить» — надо целиком перезаписывать.
Когда же SSD просят записать большой блок (больше, чем внутренний блок в SSD), то никакого выигрыша это не должно давать, просто потому, что нечего «переносить» — надо целиком перезаписывать.
То есть для мелких операций записи это реально помогающий метод — размечать не весь диск?
Я знал, что надо оставлять свободное место, но не знал, что это не связано с партициями
Я знал, что надо оставлять свободное место, но не знал, что это не связано с партициями
Разделы к этому не имеют никакого отношения. Надо понимать, что free space с точки зрения контроллера диска и файловой системы — две большие разницы. Для контроллера free space — это то, куда пока что никто не писал. Ни разу. Если записали и удалили — всё равно область с данными. Таким образом, чем больше свободного места с точки зрения контроллера, тем ему легче. Но с точки зрения контроллера fs, на которую хоть раз полностью записали все блоки, а потом переформатировали заново — всё равно полностью заполнена.
Единственные два исключения: операция TRIM и secure erase. TRIM делают многие файловые системы для ненужных данных, secure erase делается всегда руками и целиком для диска.
Когда говорят про практический underprovision'ing, то речь идёт о том, чтобы с самого начала ограничить используемое место на диске и никогда туда не писать. Иногда делают это через lba limits (то есть диск рапортует про меньшее место, чем есть), иногда через ограничение размера раздела, иногда — посредством правильного использования FS с поддержкой trim.
Эффект сильно разнится от контроллера к контроллеру, но из практических соображений иметь ФС, на которой меньше 10% свободного места — плохо. Так что обычная ФС (ext3, ext4) отлично справится с задачей underprovision'инга.
Единственные два исключения: операция TRIM и secure erase. TRIM делают многие файловые системы для ненужных данных, secure erase делается всегда руками и целиком для диска.
Когда говорят про практический underprovision'ing, то речь идёт о том, чтобы с самого начала ограничить используемое место на диске и никогда туда не писать. Иногда делают это через lba limits (то есть диск рапортует про меньшее место, чем есть), иногда через ограничение размера раздела, иногда — посредством правильного использования FS с поддержкой trim.
Эффект сильно разнится от контроллера к контроллеру, но из практических соображений иметь ФС, на которой меньше 10% свободного места — плохо. Так что обычная ФС (ext3, ext4) отлично справится с задачей underprovision'инга.
Спасибо, познавательно.
Скажите, чем вас не устроил iostat, раз вы решили написать blktop?
Скажите, чем вас не устроил iostat, раз вы решили написать blktop?
Надо понимать ситуацию, в которой писались ifstop и iostat — под сотню и больше дисков и сетевых интерфейсов клиентов, сложные маппинги lvm/raid/multipath… Если вы на такой простыне запустите iostat, то получите простыню на три экрана. Причём нагрузка скачет, то есть однократный вывод не достаточен, надо посмотреть некоторое время.
Фактически, вещи, которых не хватает в iostat
— цвета (чтобы сразу знать, куда смотреть)
— показа io_time (atop его показывает, но не для всех блочных устройств в системе)
— реального времени (показа нагрузки не «вообще», а за последние секунды)
разница такая же, как между ps и top. Одно другое не заменяет, а дополняет.
Фактически, вещи, которых не хватает в iostat
— цвета (чтобы сразу знать, куда смотреть)
— показа io_time (atop его показывает, но не для всех блочных устройств в системе)
— реального времени (показа нагрузки не «вообще», а за последние секунды)
разница такая же, как между ps и top. Одно другое не заменяет, а дополняет.
В сущности, RAID — мертвая технология.
Можно сколь-угодно натягивать кожу и колоть ботокс, но сути не меняет.
У нас в Nutanix нет никаких проблем с SSD дисками при том что используется тот-же линукс и LSI контроллер.
Но мы не используем рейд, вообще. Ни программный ни аппаратный.
LSI при этом работает прекрасно, один из лучших аппаратных контроллеров. Так что автору статьи тут скорее подходит — «вы не любите кошек? просто не умеете их готовить» :)
Нет рейда -> нет указанных в статье проблем.
Можно сколь-угодно натягивать кожу и колоть ботокс, но сути не меняет.
У нас в Nutanix нет никаких проблем с SSD дисками при том что используется тот-же линукс и LSI контроллер.
Но мы не используем рейд, вообще. Ни программный ни аппаратный.
LSI при этом работает прекрасно, один из лучших аппаратных контроллеров. Так что автору статьи тут скорее подходит — «вы не любите кошек? просто не умеете их готовить» :)
Нет рейда -> нет указанных в статье проблем.
Во-первых, nutanix ровно так же получит бобо от кривых LSI'ных дров, как и все остальные. (или есть супертехнология превращения кривых дров в некривые?).
Во-вторых, после исключения драйверов и хардварного рейда мы получили 10% разницы между теорией и практикой. Вы говорите, что у вас «нет рейда -> нет проблем», а какая производительность на 6-10 SSD'шках в страйпе/без реданданси будет? А в сравнении с конфигом на одной SSD'шке? Тестировали? Покажите? (я не уверен, что кто-то заметит 10% просто так; я заметил, потому что следил за цифрами по мере устранения боттлнеков).
Во-вторых, после исключения драйверов и хардварного рейда мы получили 10% разницы между теорией и практикой. Вы говорите, что у вас «нет рейда -> нет проблем», а какая производительность на 6-10 SSD'шках в страйпе/без реданданси будет? А в сравнении с конфигом на одной SSD'шке? Тестировали? Покажите? (я не уверен, что кто-то заметит 10% просто так; я заметил, потому что следил за цифрами по мере устранения боттлнеков).
Подозреваю на аппаратных рейдах под SSD, проблема решается большим кэшем.
Думаю что скоро будет развитие технологий отложенной записи в оперативную память, например сейчас это реализовано в SSD гражданской версии PlexTurbo от Plextor или в Самсунге EVO.
Если подобные решения перейдут в enterprise, то такая схема решит подобную проблему и на софтовых рэйдах
Думаю что скоро будет развитие технологий отложенной записи в оперативную память, например сейчас это реализовано в SSD гражданской версии PlexTurbo от Plextor или в Самсунге EVO.
Если подобные решения перейдут в enterprise, то такая схема решит подобную проблему и на софтовых рэйдах
Надо, всего-то, сделать асинхронный raid-контроллер, который не будет ждать пока операцию выполнит каждый диск, чтобы начать новую.
Как вы представляете себе асинхронный raid0? В случае падения одного диска вы как можно быстрее должны сообщить системе, о том, что массив развалился. Если не согласны, можете сразу в /dev/null писать :)
В чем проблема?
Если у нас есть 2 операции на запись. Что мешает запустить 2ю пока первая не завершилась? А системе об успехе операции записи мы сообщаем когда она фактически завершилась. Нет. Не вижу проблем.
Если у нас есть 2 операции на запись. Что мешает запустить 2ю пока первая не завершилась? А системе об успехе операции записи мы сообщаем когда она фактически завершилась. Нет. Не вижу проблем.
Если в контроллере включен кеш на запись — он тогда так и будет работать: См. выше Т.е. все уже придумано до нас.
Если кеша нет, то в момент сбоя ссд встанет ридонли (правильная смерть). А вы начали следующую операцию. Или уже даже следующую за ней…
Если кеша нет, то в момент сбоя ссд встанет ридонли (правильная смерть). А вы начали следующую операцию. Или уже даже следующую за ней…
Иии?
Возьмем за правило операция может быть закончена только после того как будут закончены все операции начатые до начала операции. Все. Никаких проблем. В случае сбоя, винт переходит в ридонли и все начатые операции завершаются с ошибкой. Никаких проблем.
Возьмем за правило операция может быть закончена только после того как будут закончены все операции начатые до начала операции. Все. Никаких проблем. В случае сбоя, винт переходит в ридонли и все начатые операции завершаются с ошибкой. Никаких проблем.
В контексте raid0 пофигу, в контексте обычных рейдов это называется «очередь» и на реальных данных работает ограниченно, потому что в какой-то момент ОС говорит «стоп, запиши СНАЧАЛА это». И вся очередь начинает писаться. А софт ждёт, пока допишется. Получается внезапный и очень неприятный всплеск latency.
Нельзя сделать очередь подлиннее так, чтобы в ней ждали поменьше (любому человеку в супермаркете это очевидно).
Нельзя сделать очередь подлиннее так, чтобы в ней ждали поменьше (любому человеку в супермаркете это очевидно).
Хм, простите, а увеличение chunk не дает увеличения скорости? Какой он у вас сейчас кстати?
Ведь если куски данных которые пишет каждый диск будут достаточно большими, чтобы зацепить несколько областей, то на каждом диске будет усреднение. И вы тогда получите не сложение минимумов, а сложение «средних».
И ещё. Вы не любите LSI. А что вам нравится больше? Какой HBA на много портов выбрать-то?
Ведь если куски данных которые пишет каждый диск будут достаточно большими, чтобы зацепить несколько областей, то на каждом диске будет усреднение. И вы тогда получите не сложение минимумов, а сложение «средних».
И ещё. Вы не любите LSI. А что вам нравится больше? Какой HBA на много портов выбрать-то?
Я пробовал менять chunk, при росте chunk'а скорость падает.
Из всех HBA я не имею ни малейшего нарекания только к intel'ам. Точнее, у них есть проблема с потолком производительности, но зато никаких глюков я от них никогда не видел. К сожалению, 6 портов максимум, sata, и только в составе чипсета.
Подавал надежды adaptec'овский HBA (не путать с рейдами) — но когда я его видел (через пол-года после анонса) он был ещё сырой-сырой-сырой. В том смысле, что драйверов в апстриме не было, только сырцы на сайте самого адаптека. Надеюсь, они это поправили.
Из всех HBA я не имею ни малейшего нарекания только к intel'ам. Точнее, у них есть проблема с потолком производительности, но зато никаких глюков я от них никогда не видел. К сожалению, 6 портов максимум, sata, и только в составе чипсета.
Подавал надежды adaptec'овский HBA (не путать с рейдами) — но когда я его видел (через пол-года после анонса) он был ещё сырой-сырой-сырой. В том смысле, что драйверов в апстриме не было, только сырцы на сайте самого адаптека. Надеюсь, они это поправили.
Хм. А почему эта скорость падает? Чем то это должно объяснятся? Или она падает на мелких операциях? И на столько сильно, что приращение на последовательных уже становится не так важным?
Ну про интел — это понятно. Хотя, может кто-то сумеет из чипсета сделать съёмную плату и тогда будет 6*n. Но пока 6 — это предел, и он очень печальный. Я пока до 10 догоняю через ASMedia 1061 (1062). Но там всего 2 порта. Про Marvel у меня вообще печальный опыт: avryabov.livejournal.com/5056.html
А в планах собрать хранилище на 15 HDD, но тут похоже ничего лучше LSI нету. И это меня огорчает…
Ну про интел — это понятно. Хотя, может кто-то сумеет из чипсета сделать съёмную плату и тогда будет 6*n. Но пока 6 — это предел, и он очень печальный. Я пока до 10 догоняю через ASMedia 1061 (1062). Но там всего 2 порта. Про Marvel у меня вообще печальный опыт: avryabov.livejournal.com/5056.html
А в планах собрать хранилище на 15 HDD, но тут похоже ничего лучше LSI нету. И это меня огорчает…
Падает она на ожидании внезапного протупления — то есть если один диск протупил, остальные ждут.
Насчёт marvel спасибо, буду знать.
Насчёт marvel спасибо, буду знать.
Дык внезапные протупления и на меньших чунках бывают.
Или получается так, что на меньших чунках вероятность протупления одного из дисков далеко не 100%, а сильно меньше?
Но даже тут не должно быть снижения производительности.
Просто моя идея была в том, чтобы протупления дисков друг на друга накладывались. Чтобы диски тупили параллельно.
Сейчас у тебя один тупит — а другие уже отработали. И быстрые ждут тормоза. Если чунк большой — то каждому диску достается большой кусок, и он с высокой вероятностью будет и тупить, и быстро работать, просто на разных местах. Один в начале тормознет, второй в конце, третий в середине, но к финишу все приедут примерно вместе.
Возможные замедления в такой схеме могут быть с нескольких сторон:
1. на мелких операциях, которые раньше раскладывались на несколько дисков, а сейчас упираются в производительность меньшего количества.
2. буфера в системе/приложении которые пишут инфу на диск, не большие, и при большом чунке их тупо не хватает, чтобы нагрузить все диски параллельно, и из восьми работает например 4, а следующие четыре начнут писать только после того, как эти закончат свою работу, когда система отдаст приложению ответ — с этими данными я закончила, давай следующие.
Первое — это принципиальное понижение производительности, и тут ничего нельзя сделать. А второе — потенциально излечимо.
Или я какой-то другой механизм снижения производительности пропустил?
Или получается так, что на меньших чунках вероятность протупления одного из дисков далеко не 100%, а сильно меньше?
Но даже тут не должно быть снижения производительности.
Просто моя идея была в том, чтобы протупления дисков друг на друга накладывались. Чтобы диски тупили параллельно.
Сейчас у тебя один тупит — а другие уже отработали. И быстрые ждут тормоза. Если чунк большой — то каждому диску достается большой кусок, и он с высокой вероятностью будет и тупить, и быстро работать, просто на разных местах. Один в начале тормознет, второй в конце, третий в середине, но к финишу все приедут примерно вместе.
Возможные замедления в такой схеме могут быть с нескольких сторон:
1. на мелких операциях, которые раньше раскладывались на несколько дисков, а сейчас упираются в производительность меньшего количества.
2. буфера в системе/приложении которые пишут инфу на диск, не большие, и при большом чунке их тупо не хватает, чтобы нагрузить все диски параллельно, и из восьми работает например 4, а следующие четыре начнут писать только после того, как эти закончат свою работу, когда система отдаст приложению ответ — с этими данными я закончила, давай следующие.
Первое — это принципиальное понижение производительности, и тут ничего нельзя сделать. А второе — потенциально излечимо.
Или я какой-то другой механизм снижения производительности пропустил?
Админское:
Я теперь тоже не люблю LSI.
Купил 9750-4i, обнаружил, что если включить кэширование записи — скорость возрастает (ожидаемо).
А вот если включить кэширование записи с батарейной защитой — скорость уменьшается.
После долгого треда с техподдержкой мне сообщили, что так и должно быть.
Зачем тогда нужно кэширование записи мне не сказали.
прошивка и последняя и не последняя, один чёрт.
Я теперь тоже не люблю LSI.
Купил 9750-4i, обнаружил, что если включить кэширование записи — скорость возрастает (ожидаемо).
А вот если включить кэширование записи с батарейной защитой — скорость уменьшается.
После долгого треда с техподдержкой мне сообщили, что так и должно быть.
Зачем тогда нужно кэширование записи мне не сказали.
прошивка и последняя и не последняя, один чёрт.
Неприятная вещь. А они никаких объяснений этой логике не дают? Как вариант, если батарея есть, но не включена на уровне контроллера, тормоза есть? Если из, скажем, 4 дисков на контроллере с батареей собрать два зеркала, в первом включить кеширование, во втором — нет, то тормоза в обоих есть?
Всем давно известно, что кэш на запись при использовании SSD надо отключать.
Объяснение было «а, окей, так и должно работать»
На вопрос — а зачем тогда вообще нужен кэш записи, не ответили.
Оно так себя ведёт вне зависимости от количества дисков, от включение-выключения кэша на чтение, от того, есть ли второй том без кэша записи.
А вот второй том (который без кэша) работает нормально.
При чём — обратите внимание — с включённым кэшем записи и батареей — оно работает МЕДЛЕННЕЕ.
При чём заметно, чуть ли не на 30-50% (уже точно не помню цифру, но это не пара процентов)
перетыкал диски в Adaptec-овский контроллер — всё хоккей
На вопрос — а зачем тогда вообще нужен кэш записи, не ответили.
Оно так себя ведёт вне зависимости от количества дисков, от включение-выключения кэша на чтение, от того, есть ли второй том без кэша записи.
А вот второй том (который без кэша) работает нормально.
При чём — обратите внимание — с включённым кэшем записи и батареей — оно работает МЕДЛЕННЕЕ.
При чём заметно, чуть ли не на 30-50% (уже точно не помню цифру, но это не пара процентов)
перетыкал диски в Adaptec-овский контроллер — всё хоккей
Скорее всего брак или глючки прошивки/драйверов.
Я тоже пободался с поддержкой одного вендора, когда в пришедшем сервере RAID-контроллер выдавал жуткую latency. Вначале проблему признавать отказывались, написав, что это нормально:
Я тоже пободался с поддержкой одного вендора, когда в пришедшем сервере RAID-контроллер выдавал жуткую latency. Вначале проблему признавать отказывались, написав, что это нормально:
Мы воспроизвели ситуацию (RAID10 на этих шести дисках, запись нулями при создании): средние задержки около 850 ms, больше 1000 не поднимается. Потом добавили два SSD в RAID0: задержки около 400 ms.
Скажите, а HBA с SSD-specific мелочами, вроде TRIM, как себя ведут? Грубо, передают то, что ОСь отдала в сторону диска(-ов), и эту проблему перекладывает на плечи ОСи, или сам о том помнит и сам же делает? А плата RAID в этом смысле как себя вела?
Я к тому, что не может ли оно влиять (по крайней мере, в реально жизни, а не при записи байтов от начала к концу) на поведение дисков?
Я к тому, что не может ли оно влиять (по крайней мере, в реально жизни, а не при записи байтов от начала к концу) на поведение дисков?
Пожалуйста уберите линии из графиков. Какой в них смысл? Вы измеряете значения дискретной величины, подразумевать непрерывность нет смысла. Более того, на самом первом графике характер кривой меняется на величине 5,5 дисков. Что это значит? Что вызывает такой эффект?
Не далее чем сегодня задался вопросом исследования производительности RAID-0. Началось все с того что при создании индексов в большой (300Gb) базе данных. Загрузка легла на плечи одного SSD. %util в iostat -x показывал 6% 100% 6%. При этом, это не было похоже, на загрузку из-за высокой latency диска. Т.к. чтение с загруженного диска было 200мб/cек, а с двух оставшихся по 16мб/сек. Chunk size 512k. Как такое получилось пока у меня в голове не укладывается. Возможно у топик стартера или собравшихся будут идеи по этому поводу? Я пока пройдусь тестами по дискам массива и по массиву в собранном состоянии. Чтобы кроме цифр iostat были и графики.
Прогнал тесты и нашел причину. т.к. для работы raid использовалось 3 диска 128, 120 и 256 (собирали из того что было :)). большая часть объема raid-0 успешно использовала все 3 диска, и только 128 GB в хвосте работали напрямую только с большим диском. потому и проседала скорость когда диск заполнялся почти полностью. Для более опытных коллег, может это и было очевидно. Ну а я сегодня узнал что-то новое. :)
Прошу прощения за некропостинг, возникло интересное предположение, и очень захотелось его проверить. Если, конечно, автор статьи ещё помнит и мониторит ответы на свои статьи.
Вопрос следующий. Не была ли запись на SSD, график скорости которой показан на первой картинке, первой записью по всей поляне после покупки SSD? Ступенька могла быть связана с формированием транслятора «на лету». А при следующем замере, уже с обновлённым драйвером, транслятор уже был сформирован, и поэтому график стал ровным.
Вопрос следующий. Не была ли запись на SSD, график скорости которой показан на первой картинке, первой записью по всей поляне после покупки SSD? Ступенька могла быть связана с формированием транслятора «на лету». А при следующем замере, уже с обновлённым драйвером, транслятор уже был сформирован, и поэтому график стал ровным.
Спасибо.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
SSD + raid0 — не всё так просто