Комментарии 165
Точно, четко, емко — спасибо!
Как раз будем мерить производительность хранилищ.
Как раз будем мерить производительность хранилищ.
Спасибо за подробую статью!
Достаточно сказать, что в линуксе существует 12 разных алгоритмов контроля заторов в сети (congestion), которые предназначены для разных ситуаций. И есть около 20 параметров ядра, каждый из которых может радикальным образом повлиять на попугаи на выходе (пардон, результаты теста).
А не подскажете, где можно об этом подробнее почитать?
А не подскажете, где можно об этом подробнее почитать?
Очень много где. Про congestion алгоритмы — в гугле «tcp congestion linux» — очень много даже (на мой взгляд) слишком подробных публикаций.
Список доступных алгоритмов:
$ find /lib/modules/3.2.0-30-generic-pae/ -name «tcp_*»
/lib/modules/3.2.0-30-generic-pae/kernel/net/ipv4/tcp_htcp.ko
/lib/modules/3.2.0-30-generic-pae/kernel/net/ipv4/tcp_scalable.ko
/lib/modules/3.2.0-30-generic-pae/kernel/net/ipv4/tcp_yeah.ko
/lib/modules/3.2.0-30-generic-pae/kernel/net/ipv4/tcp_highspeed.ko
/lib/modules/3.2.0-30-generic-pae/kernel/net/ipv4/tcp_bic.ko
/lib/modules/3.2.0-30-generic-pae/kernel/net/ipv4/tcp_diag.ko
/lib/modules/3.2.0-30-generic-pae/kernel/net/ipv4/tcp_probe.ko
/lib/modules/3.2.0-30-generic-pae/kernel/net/ipv4/tcp_vegas.ko
/lib/modules/3.2.0-30-generic-pae/kernel/net/ipv4/tcp_veno.ko
/lib/modules/3.2.0-30-generic-pae/kernel/net/ipv4/tcp_westwood.ko
/lib/modules/3.2.0-30-generic-pae/kernel/net/ipv4/tcp_hybla.ko
/lib/modules/3.2.0-30-generic-pae/kernel/net/ipv4/tcp_illinois.ko
/lib/modules/3.2.0-30-generic-pae/kernel/net/ipv4/tcp_lp.ko
Список доступных алгоритмов:
$ find /lib/modules/3.2.0-30-generic-pae/ -name «tcp_*»
/lib/modules/3.2.0-30-generic-pae/kernel/net/ipv4/tcp_htcp.ko
/lib/modules/3.2.0-30-generic-pae/kernel/net/ipv4/tcp_scalable.ko
/lib/modules/3.2.0-30-generic-pae/kernel/net/ipv4/tcp_yeah.ko
/lib/modules/3.2.0-30-generic-pae/kernel/net/ipv4/tcp_highspeed.ko
/lib/modules/3.2.0-30-generic-pae/kernel/net/ipv4/tcp_bic.ko
/lib/modules/3.2.0-30-generic-pae/kernel/net/ipv4/tcp_diag.ko
/lib/modules/3.2.0-30-generic-pae/kernel/net/ipv4/tcp_probe.ko
/lib/modules/3.2.0-30-generic-pae/kernel/net/ipv4/tcp_vegas.ko
/lib/modules/3.2.0-30-generic-pae/kernel/net/ipv4/tcp_veno.ko
/lib/modules/3.2.0-30-generic-pae/kernel/net/ipv4/tcp_westwood.ko
/lib/modules/3.2.0-30-generic-pae/kernel/net/ipv4/tcp_hybla.ko
/lib/modules/3.2.0-30-generic-pae/kernel/net/ipv4/tcp_illinois.ko
/lib/modules/3.2.0-30-generic-pae/kernel/net/ipv4/tcp_lp.ko
Рекомендую вот эту книгу: https://intronetworks.cs.luc.edu/
Начиная с 17й главы много полезной информации о том как tcp работает
Вот после таких статей от amarao и его других заметок об облачных системах начинаешь понимать, что нифига не шаришь в ИТ.
Спасибо конечно =Ъ, но низкий поклон, шаркая ножкой.
Спасибо конечно =Ъ, но низкий поклон, шаркая ножкой.
И много storage-специалистов знают про производительность rbd?
Про rbd интересно, кстати. В результатх фигурирует пара 200kIOPS / 0.1ms при iodepth=2, a что там происходит при увеличении iodepth?
Снижаются попугаи. Насколько я понимаю, на таких скоростях оверхед самого fio и стека блочных устройств линукса начинает играть более значительную роль, чем пропускная способность памяти. Почему именно 2? Полагаю, что он приводит к ситуации «один запрос обрабатывается стеком, второй в этот момент — в fio». И каждый из них может обрабатывать один запрос в один момент времени.
Вы наверно имели в виду brd?
На мой взгляд измерять его производительность вообще бессмысленно, потому что операции к нему как к блочному устройству никогда не завершаются. Убедитесь глядя в blktrace.
На мой взгляд измерять его производительность вообще бессмысленно, потому что операции к нему как к блочному устройству никогда не завершаются. Убедитесь глядя в blktrace.
Хотя нет, отсутствие завершений — это проблема самого драйвера brd, который переопределяет метод постановки в очередь, в котором и выполняет чтение/запись (и, возможно, выделение страниц) синхронно, но не вызывает по окончании blk_update_request.
brd, он самый.
Собственно, я его использовал для отладки сетевого стека — IO на него я полагал в пределах производительности СХД равным бесконечности, т.е. весь возникающий оверхед был связан с параметрами tcp, iscsi target'а и initiator'а.
Собственно, я его использовал для отладки сетевого стека — IO на него я полагал в пределах производительности СХД равным бесконечности, т.е. весь возникающий оверхед был связан с параметрами tcp, iscsi target'а и initiator'а.
Статья отличная, но искренне не считаю, что обладание набором таких знаний говорит о полной «прошаренности» в IT, и наоборот :)
Честно говоря, я вашу мысль не понял.
Я всего лишь написал про методологию измерения производительности дисковой подсистемы, не более. Ну как бы если бы в автомобильном топике объясняли, что величина «секунд до сотни» важнее, чем «число лошадей».
Я всего лишь написал про методологию измерения производительности дисковой подсистемы, не более. Ну как бы если бы в автомобильном топике объясняли, что величина «секунд до сотни» важнее, чем «число лошадей».
Ммм… vasilisc выразил мысль, что незнание тонкостей работы стораджей и облачных систем говорит о полном невежестве в IT в целом. Я позволил себе не согласиться :)
Есть ещё вот такая интересная ссылочка: www.802dotwhat.co.uk/how-to-calculate-storage-iops.html.
Если пересказать кратко, то: создание RAID массива из нескольких дисков приводит к тому, что операция записи становится «дороже», вызывает более чем одну операцию ввода-вывода.
От себя дополню, что обычно сначала считаю теоретическую производительность, затем гоняю тесты. Если теория не сходится с практикой в разы — что-то где-то настроено криво. Если сходится с погрешностью в процентов 5 — всё отлично.
Кроме того, «как померить» — хороший вопрос. Ещё более хороший вопрос: как предсказать %)
Если пересказать кратко, то: создание RAID массива из нескольких дисков приводит к тому, что операция записи становится «дороже», вызывает более чем одну операцию ввода-вывода.
От себя дополню, что обычно сначала считаю теоретическую производительность, затем гоняю тесты. Если теория не сходится с практикой в разы — что-то где-то настроено криво. Если сходится с погрешностью в процентов 5 — всё отлично.
Кроме того, «как померить» — хороший вопрос. Ещё более хороший вопрос: как предсказать %)
кстати говоря, концовка у статьи интересная: лично наблюдаю на sata дисках по 400 iops (~380 в пике). Что в синтетических тестах, что в реальной хранилке. Что лишний раз подтверждает тезис о попугаях ;)
latency? Ещё раз повторяю, про latency <10 мс. Показывайте итог вывода fio и конфиг теста.
Пока что позвольте вам не поверить, что вы с sata'шного диска можете получить 300 IOPS с 10мс latency.
Пока что позвольте вам не поверить, что вы с sata'шного диска можете получить 300 IOPS с 10мс latency.
latency померить не могу. Но она там явно выше 10мс. У меня на той хранилке вообще «всё грустно» пока.
Ну, понимаете, я лёгким движением руки могу сконструировать хранилище из пары десятков дисков, которое на куче тестов даст офигенные iops'ы (даже в worst case), но с latency >10с.
Оно такое нужно?
Это всё равно, как если бы магазин гордился, что обслуживает вместо 40 человек в час 300, но эти триста в очереди по полтора часа стоят.
Оно такое нужно?
Это всё равно, как если бы магазин гордился, что обслуживает вместо 40 человек в час 300, но эти триста в очереди по полтора часа стоят.
Ну, я пока что не хотел постить на хабр, ибо она сырая, но вот утилита, которую мне пришлось написать, чтобы видеть ситуацию своими глазами: github.com/amarao/blktop (и я там всё ещё сомневаюсь в алгоритме рассчёта latency).
Насчёт рейда — да, с некоторыми оговорками: время записи на него равно max() от времени записи на диски (т.к. все приличные рейды пишут параллельно). Наличие write-back кеша хоть какого-то размера обычно нивелирует этот аспект. Разумеется, речь про mirror'ы, для 5-6 важнее оверхед по процессору.
Насчёт рейда — да, с некоторыми оговорками: время записи на него равно max() от времени записи на диски (т.к. все приличные рейды пишут параллельно). Наличие write-back кеша хоть какого-то размера обычно нивелирует этот аспект. Разумеется, речь про mirror'ы, для 5-6 важнее оверхед по процессору.
" I call it 'beta', because it's beta' than nothing" =)
Мне чаще приходится обходиться более-менее адекватным предсказанием производительности железки. Тесты производительности мне потом несколько бесполезны: денег на изменение конфигурации всё равно не дадут. Хотя, конечно, по итоговой конфигурации мы проходимся небольшим тестом, чтобы убедиться, что конфигурация всей хранилки верна и производительность соответствует расчётной.
Мне чаще приходится обходиться более-менее адекватным предсказанием производительности железки. Тесты производительности мне потом несколько бесполезны: денег на изменение конфигурации всё равно не дадут. Хотя, конечно, по итоговой конфигурации мы проходимся небольшим тестом, чтобы убедиться, что конфигурация всей хранилки верна и производительность соответствует расчётной.
странная статейка, почему-то raid penalty зависит от типа массива, но не зависит от количества дисков в массиве.
А под виндой SQLIO не был замечен в «неправильном» тестировании случайно?
Спасибо за статью, как раз собирались различные системы хранения сравнивать.
Скажите, ну вы видели хоть одного человека, который бы вам ответил без фантазий на вопрос «сколько вам нужно дисковых операций»? Я вот честно признался, что 10мс — это я с потолка взял.
А сколько Очень Умных Интеграторов так же берут с потолка показатели «иопсов на пользователя», но не признаются в этом?
А сколько Очень Умных Интеграторов так же берут с потолка показатели «иопсов на пользователя», но не признаются в этом?
Ну вы меня улыбаете. От того, что кто-то у какого-то дяди в какой-то конфигурации померял число iops'ов не означает, что эти iops'ы можно предлагать всем остальным.
Говорить же про «статистику реальных инсталляций» в условиях публичного облака — нонсенс.
Завтра придёт жадный человек, который себе выставит параметры MOD в 16Мб и будет бесконечно свопиться. А послезавтра придёт человек с кеширующим в память сервером, у которого всего IO — прочитать один раз да логи с dmesg'ом писать.
И нагрузка у них будет несопоставимая — минимум на порядок разница. Сейчас мы можем предоставить на виртуалку порядка 3-8кIOPS, но сколько человек их потребляют?
В условиях облака вся нагрузка воспринимается как белый шум, идущий на storage. И планирование идёт именно из характеристик интегрированной нагрузки. Да даже не планирование, а простой принцип «утилизация к 50% подобралась — надо железо заказывать, чтобы к 70% его ввести в продакт».
Говорить же про «статистику реальных инсталляций» в условиях публичного облака — нонсенс.
Завтра придёт жадный человек, который себе выставит параметры MOD в 16Мб и будет бесконечно свопиться. А послезавтра придёт человек с кеширующим в память сервером, у которого всего IO — прочитать один раз да логи с dmesg'ом писать.
И нагрузка у них будет несопоставимая — минимум на порядок разница. Сейчас мы можем предоставить на виртуалку порядка 3-8кIOPS, но сколько человек их потребляют?
В условиях облака вся нагрузка воспринимается как белый шум, идущий на storage. И планирование идёт именно из характеристик интегрированной нагрузки. Да даже не планирование, а простой принцип «утилизация к 50% подобралась — надо железо заказывать, чтобы к 70% его ввести в продакт».
Каким образом вы планируете использовать эту базу для рассчёта? Раз на 300 пользователей CRM нужно нечто с 1000IOPS, то на 500 пользователей (другой?) CRM нужно нечто на 1500 IOPS?
Ну вы поняли.
С точки зрения публичного облака, эти виртуалки:
а) появляются и исчезают случайным образом (по воле клиентов)
б) дают такую нагрузку, которую захотелось владельцу ресурса, и с ним нет никакой связи (никаких предварительных согласований типов нагрузки и т.д.)
в) их безумно много. Настолько, что даже самый крупный клиент не заметен на фоне остальной массы.
В этих условиях пытаться предсказывать нагрузку в режиме белого ящика — это страдать фигнёй.
Предсказываем в режиме чёрного ящика (т.е. есть график — по нему и работаем).
Под «белым шумом» я имел в виду, что невозможно как-то разделить «вот это трафик БД, вот это трафик веб-сервера, а вот это трафик стримкастинга». Понятно, что у нас есть вполне чётко ощутимая область горячих и тёплых точек и есть огромная масса лежащих гигабайт, к которым месяцами не обращаются.
Насчёт «чтение доминирует над записью» — нет, т.к. у виртуалок свои кеши, и чаще всего чтение хорошо закешировано со стороны клиента. (есть и обратная сторона — прошедшие операции чтения — т.к. «холодное чтение», то есть нифига не кешируемое и самое проблемное).
Белый шум — я имел в виду, что мы не выделяем конкретных приложений. Идёт «поток», этот поток обслуживается. Все виды анализа — только статистические (и вот тут человек в комментариях подсказал blktrace, будем и его использовать), без попытки вникать в предметную область клиентов.
Ну вы поняли.
С точки зрения публичного облака, эти виртуалки:
а) появляются и исчезают случайным образом (по воле клиентов)
б) дают такую нагрузку, которую захотелось владельцу ресурса, и с ним нет никакой связи (никаких предварительных согласований типов нагрузки и т.д.)
в) их безумно много. Настолько, что даже самый крупный клиент не заметен на фоне остальной массы.
В этих условиях пытаться предсказывать нагрузку в режиме белого ящика — это страдать фигнёй.
Предсказываем в режиме чёрного ящика (т.е. есть график — по нему и работаем).
Под «белым шумом» я имел в виду, что невозможно как-то разделить «вот это трафик БД, вот это трафик веб-сервера, а вот это трафик стримкастинга». Понятно, что у нас есть вполне чётко ощутимая область горячих и тёплых точек и есть огромная масса лежащих гигабайт, к которым месяцами не обращаются.
Насчёт «чтение доминирует над записью» — нет, т.к. у виртуалок свои кеши, и чаще всего чтение хорошо закешировано со стороны клиента. (есть и обратная сторона — прошедшие операции чтения — т.к. «холодное чтение», то есть нифига не кешируемое и самое проблемное).
Белый шум — я имел в виду, что мы не выделяем конкретных приложений. Идёт «поток», этот поток обслуживается. Все виды анализа — только статистические (и вот тут человек в комментариях подсказал blktrace, будем и его использовать), без попытки вникать в предметную область клиентов.
Интересно, а существует ли какое-то способ проанализировать микс операций ввода-вывода, чтобы определить размер и взаимное соотношение в потоке блоков ввода-вывода, чтобы получить на выходе что-то «гистограммное»: за час операций блоками 4K — 73% IO, блоками 64K — 8%, блоками 512b — 6%, и так далее?
У меня давно чешутся руки написать что-то типа dm_log, который бы представлял из себя device mapper устройство, которое бы просто писало лог операций с таймстемпами, пропуская реальные данные дальше вниз по стеку. Т.е. на выходе мы имели бы лог с данными о том, когда, куда и сколько писали. А на него уже можно было бы натравливать всякие R для поиска закономерностей…
Увы, это всё фантазии.
Увы, это всё фантазии.
Большое спасибо за статью — очень ко времени.
В качестве тестов(параллельно с fio) используем еще нагрузку ORION Oralcle, утилита бесплатна и предоставляет различные варианты операций с дисками, ну и предполагает эмуляцию работы БД(Oracle'овой как минимум). Есть ли у вас опыт работы с этим тестом — интересно мнение?
В качестве тестов(параллельно с fio) используем еще нагрузку ORION Oralcle, утилита бесплатна и предоставляет различные варианты операций с дисками, ну и предполагает эмуляцию работы БД(Oracle'овой как минимум). Есть ли у вас опыт работы с этим тестом — интересно мнение?
Да, в тесте можно запускать отдельно RR/RW; SR/SW; определять количество тредов, размеры блоков, имитация рейдов… и да, Latency показывает, для нас это тоже ключевой момент. Про работу без кеша сказать точно не могу.
Ну, если убрать такое сомнительное преимущество как «оно написано ораклом», то у fio есть сырцы, да и употребляется он чаще. Если же отдаться в рабство работать с ораклом, то его утилиты юзать надо, ибо они лучше других знают про паттерны нагрузки своей субд.
В условиях же случайной и заранее неизвестной нагрузки, лучше работать с тестами worst case.
В условиях же случайной и заранее неизвестной нагрузки, лучше работать с тестами worst case.
Просто из любопытства спрошу — а зачем изобретать велосипед, если есть www.storageperformance.org с вполне себе оформившейся и устоявшейся методологией? Бери и пользуйся.
Ты забыл про spew.
ЗЫ и, имхо, глубину очереди вскользь как-то описал. могут не понять.
Почитал man к ней, откровенно не понял, в чём прелесть. Нет возможности пустить задачи в параллель (т.е. чтение всегда зависимо от записи). В третьих из rw там только read after write, т.е. сплошное хождение по кешу. А можно мне так, чтобы оно писало рандомом и при этом читало с других мест? А в несколько потоков?
Плюс я не увидел у него latency в выводе, т.е. смысла в этой утилите никакого.
Что можно сказать про диск, у которого вот такие попугаи:
RTR: 2091.45 KiB/s Transfer time: 00:00:31 IOPS: 522.86
Плюс я не увидел у него latency в выводе, т.е. смысла в этой утилите никакого.
Что можно сказать про диск, у которого вот такие попугаи:
RTR: 2091.45 KiB/s Transfer time: 00:00:31 IOPS: 522.86
сложно сказать, так как service time (latency) не указан… Вообще, 522 IOPS очень странная цифра… для одного диска многовато. Это raid ил 2-3 дисков? Либо много кеш хитов
Это странно слышать от тебя «почитал ман», не далее как два года назад и ты, и я отлично мерили иопсы дисков именно ей. (гули spew по своему и моему жж).
В параллель — да, нету.
Чтение после записи — ну если размер тестируемой области достаточно большой, кеши можно пробить.
Латентность я смотрел отдельно системными утилитами, да, не так удобно, но количественные показатели можно понять.
В параллель — да, нету.
Чтение после записи — ну если размер тестируемой области достаточно большой, кеши можно пробить.
Латентность я смотрел отдельно системными утилитами, да, не так удобно, но количественные показатели можно понять.
Полистал. Да, был неопытным, даже нашёл fio, но пропустил, не поняв всей её прелести. spew настолько забыл, что вот, пришлось вспоминать с нуля.
Без latency ни один тест не интересен. Потому что тот же wd green аж под 90 IOPS выдаёт.… При latency в 500мс.
Сейчас, когда я на эту тему два года потратил, я могу сказать, что fio реализует 90% нужного функционала.
Я бы не отказался от функции «мерять число IOPS'ов при фиксированной latency», то есть автоматический подбор числа iodepth, но даже без этого оно неплохо.
Вторая претензия к fio — немного неровный рандом, который явно задирает производительность к концу теста.
Без latency ни один тест не интересен. Потому что тот же wd green аж под 90 IOPS выдаёт.… При latency в 500мс.
Сейчас, когда я на эту тему два года потратил, я могу сказать, что fio реализует 90% нужного функционала.
Я бы не отказался от функции «мерять число IOPS'ов при фиксированной latency», то есть автоматический подбор числа iodepth, но даже без этого оно неплохо.
Вторая претензия к fio — немного неровный рандом, который явно задирает производительность к концу теста.
Да нет, ты меня уже убедил в правильности fio, я уже пару месяцев ей тыкаю свою помойку.
Вот я потому и пишу, что надо график от латентности строить (собственно я это говорил еще два года назад, но у меня не было средств/желания/времени такое соорудить). тогда будет видно, какие iops мы можем получить в хорошей области (до 10, до 20 мс), а какие за пределами.
Вот я потому и пишу, что надо график от латентности строить (собственно я это говорил еще два года назад, но у меня не было средств/желания/времени такое соорудить). тогда будет видно, какие iops мы можем получить в хорошей области (до 10, до 20 мс), а какие за пределами.
Выглядит ркуто. Это кто так мило делает и на ком? судя по стартовой точке это на магнитных дисках.
Сколько шпинделей? Цена?
А теперь давайте считать вместе экономику этого 3par.
1920 дисков в 6/60ом рейде с хотспарами будет примерно (утрирую) 1700 дисков полезных. Итого 1728*146=252Тб.
По нашим ценам это будет приносить 4.5р*252=1134р/час. То есть примерно 9.9 миллиона в год. При полной загрузке. Стоимость железки 174 миллиона. Итого — 17 лет окупаемости.
Я, конечно, лукавлю, IOPS'ы вполне приносят деньги. Но даже если мы утроим годовую выручку, всё равно это нерентабельно. (А ещё надо не забывать про клиентов, которые «положили диск и забыли», т.е. IO не генерируют).
Рынок IaaS уже достаточно сформировавшийся, чтобы цены на нём диктовались не себестоимостью.
И указанное решение в эту цену не укладывается.
1920 дисков в 6/60ом рейде с хотспарами будет примерно (утрирую) 1700 дисков полезных. Итого 1728*146=252Тб.
По нашим ценам это будет приносить 4.5р*252=1134р/час. То есть примерно 9.9 миллиона в год. При полной загрузке. Стоимость железки 174 миллиона. Итого — 17 лет окупаемости.
Я, конечно, лукавлю, IOPS'ы вполне приносят деньги. Но даже если мы утроим годовую выручку, всё равно это нерентабельно. (А ещё надо не забывать про клиентов, которые «положили диск и забыли», т.е. IO не генерируют).
Рынок IaaS уже достаточно сформировавшийся, чтобы цены на нём диктовались не себестоимостью.
И указанное решение в эту цену не укладывается.
5 885 148$
«1920 дисков 146GB 15K RPM»
и этому противопоставляется
нетапп с
«432 диска 450GB 15K RPM».
«1920 дисков 146GB 15K RPM»
и этому противопоставляется
нетапп с
«432 диска 450GB 15K RPM».
Думаю, что самосбор, даже с учетом резервирования, обходится заметно дешевле.
Мне кажется, что не ушел.
Цена для такой демпинговой услуги — очень важна. И если они будут покупать готовые сторы — у них взлетит или единомоментно цена на диск в облаке (причем сразу раз в 10-20), или уменьшится время окупаемости — а это не интересно инвесторам.
Цена для такой демпинговой услуги — очень важна. И если они будут покупать готовые сторы — у них взлетит или единомоментно цена на диск в облаке (причем сразу раз в 10-20), или уменьшится время окупаемости — а это не интересно инвесторам.
Если вы мне расскажите, как оный SPC-1 запускать, запущу. У них на сайте как-то совсем невнятно и без ссылки на сырцы/бинарник.
SPC-1 в «коробочном виде» стоит денег, довольно больших, как я знаю.
Но существует довольно подробное «описание словами», по которому, при T -> бесконечность можно попробовать его реверсинжинирить.
Или, по крайней мере, взять из него полезное относительно workload. Это конечно не будет бенчмарком SPC-1, в смысле полученными результатами нельзя будет меряться с результатами официального SPC-1, но внутри себя — как вариант.
Но существует довольно подробное «описание словами», по которому, при T -> бесконечность можно попробовать его реверсинжинирить.
Или, по крайней мере, взять из него полезное относительно workload. Это конечно не будет бенчмарком SPC-1, в смысле полученными результатами нельзя будет меряться с результатами официального SPC-1, но внутри себя — как вариант.
У нас сейчас нет такого количества шпинделей.
В среднем одна коробочка (4U) показывает примерно 6-10к IOPS.
В среднем одна коробочка (4U) показывает примерно 6-10к IOPS.
Я бы не отказался от функции «мерять число IOPS'ов при фиксированной latency», то есть автоматический подбор числа iodepth, но даже без этого оно неплохо.
Сейчас (спустя 2 года) такая возможность есть:
# Test job that demonstrates how to use the latency target
# profiling. Fio will find the queue depth between 1..128
# that fits within the latency constraints of this 4k random
# read workload.
[global]
bs=4k
rw=randread
random_generator=lfsr
direct=1
ioengine=libaio
iodepth=128
# Set max acceptable latency to 500msec
latency_target=500000
# profile over a 5s window
latency_window=5000000
# 99.9% of IOs must be below the target
latency_percentile=99.9
[device]
filename=/dev/sda
В копилку: Oracle Compilebench. Эмулирует нагрузку на файловую систему, сильно похожую на компиляцию ядра линукса. Очень полезно для тестирования подобного паттерна нагрузки и для тестирования верхнего уровня — файловой системы.
Статья хороша, но ведь людям иногда нужна банальность, простой линейный тест чтения/записи, ибо не все производители делают винты так чтобы они справлялись как раз в том самом узком горлышке, а именно SATA/SAS/ATA (начиная от того момента как пользователь захотел отправить поток данных и как этот поток прошел через все контроллеры, шлейфы(а может и оптика или медь) и невесь как попало на винт, вот иногда важно ведь знать сможет прожевать интерфейс, или заткнется где нибудь по пути… В общем я считаю dd приминимо, но в своих целях.
dd (c iflag=direct) используется в основном для проверки «оно там вообще живо или нет?». Ничего осмысленного из цифр dd для себя сказать нельзя.
Собственно — у нас хранилище выдаёт примерно 50-80Мб/с на виртуалку при 4-8к IOPS (latency <10), рядом у меня лежит WD green, который выдаёт 110Мб/с при 40 IOPS и latency >20. Кто из них быстрее?
Собственно — у нас хранилище выдаёт примерно 50-80Мб/с на виртуалку при 4-8к IOPS (latency <10), рядом у меня лежит WD green, который выдаёт 110Мб/с при 40 IOPS и latency >20. Кто из них быстрее?
«Прямой линейный тест чтения-записи» строго говоря нужен только для одного — для бэкапа (ну, ОК, еще для DSS-баз, возможно). А это все же довольно частная и узкая задача, совершенно не массовая.
Внезапно: если на СХД приходит большая нагрузка, то вроде бы линейный бэкап превращается в +100500 к random IO.
PS NL-storage (write once, read rare) отдельный мир. Я с ним в продакте не имел дела, по своей домашней коллекции, о которой я думаю, там ключевым фактором является надёжность, цена, энергопотребление и время первого доступа.
PS NL-storage (write once, read rare) отдельный мир. Я с ним в продакте не имел дела, по своей домашней коллекции, о которой я думаю, там ключевым фактором является надёжность, цена, энергопотребление и время первого доступа.
Возможно, мы по терминологии не понимаем друг друга.
Я говорю: если делать бэкап LUN'а, который сильно занят, то для него процесс чтения (вроде бы линейный) будет мало отличаться от рандомного IO, т.к. в очереди будет дофига других запросов.
Я говорю: если делать бэкап LUN'а, который сильно занят, то для него процесс чтения (вроде бы линейный) будет мало отличаться от рандомного IO, т.к. в очереди будет дофига других запросов.
Выше я говорил скорее про то, что, в real life показатели секвентального чтения-записи не интересны почти совсем, отчасти потому что это очень узкий набор задач, который юзает sequental, отчасти вот из-за микса, в котором сегодня рандом преобладает по определению многозачачных систем.
Потому и непонятно отчего все еще «копирование BD-рипа в Тоталкоммандере» все еще (часто) используется в качестве измерения параметра диска.
Потому и непонятно отчего все еще «копирование BD-рипа в Тоталкоммандере» все еще (часто) используется в качестве измерения параметра диска.
Автор вроде все расписал, а чего-то не хватает. А именно:
— ничего не сказано про такой параметр как утилизация дисков. В случае если мы говорим об отдельном диске — это легко меряется. Например вот тут, слайды 12-15
www.ruoug.org/events/20091111/perf_IO_presentation.pdf
— про SAN/ NAS ни разу не надо тестить с нескольких серверов. Один сервер запросто генерит такую нагрузку чтобы напрочь убить любую дисковую подсистему. Характер нагрузки при этом легко настраивается увеличением числа параллельных потоков.
— ничего не сказано про такой параметр как утилизация дисков. В случае если мы говорим об отдельном диске — это легко меряется. Например вот тут, слайды 12-15
www.ruoug.org/events/20091111/perf_IO_presentation.pdf
— про SAN/ NAS ни разу не надо тестить с нескольких серверов. Один сервер запросто генерит такую нагрузку чтобы напрочь убить любую дисковую подсистему. Характер нагрузки при этом легко настраивается увеличением числа параллельных потоков.
У нас SAN — 10G. Одиночный хост на стор давал около 15кIOPS по одному TCP-линку. Когда я рядом поставил второй хост, каждый из них давал 15кIOPS. Потом я поставил все хосты из лаборатории (6шт) — и получил по 15к на каждый.
Утилизация на сторе росла, общая латенси тоже, но всё в пределах нормы (т.е. latency <10мс). Когда я начал играться с TCP, я добился, что единичный хост стал выжимать до 36к IOPS, но это был потолок (потом я подумал и вернул обратно — 15к на хост выглядит более чем разумно).
Если вы думаете, что единичный сервер может положить любую дисковую подсистему — добро пожаловать к нам в облако. За ваши деньги — неограниченные IOPS'ы. Заметим, без затруднений для клиентов вокруг.
Утилизация на сторе росла, общая латенси тоже, но всё в пределах нормы (т.е. latency <10мс). Когда я начал играться с TCP, я добился, что единичный хост стал выжимать до 36к IOPS, но это был потолок (потом я подумал и вернул обратно — 15к на хост выглядит более чем разумно).
Если вы думаете, что единичный сервер может положить любую дисковую подсистему — добро пожаловать к нам в облако. За ваши деньги — неограниченные IOPS'ы. Заметим, без затруднений для клиентов вокруг.
Подождите, откуда TCP в SAN? Вы кажется путаете SAN (Fibre channel) c чем-то еще.
Спасибо, за предложение, но у меня есть собственный опыт на эту тему. Обычный proliant с двумя 4GB карточками запросто генерит 60,000 IOPS, и это далеко не предел, так как мы уперлись на стороне массива.
По поводу вашего теста, надо смотреть детали. Я не уверен какой массив вы тестировали, но видимо какой-то большой.
То есть чтобы давать 36k IOPS при ~120 IOPS/диск вам нужно ~ 300 физических дисков.
Спасибо, за предложение, но у меня есть собственный опыт на эту тему. Обычный proliant с двумя 4GB карточками запросто генерит 60,000 IOPS, и это далеко не предел, так как мы уперлись на стороне массива.
По поводу вашего теста, надо смотреть детали. Я не уверен какой массив вы тестировали, но видимо какой-то большой.
То есть чтобы давать 36k IOPS при ~120 IOPS/диск вам нужно ~ 300 физических дисков.
SAN — это любая storage area network. А FC там, инфинибэнд или 10G — нет никакой разницы.
FC это слишком сурово для публичных облаков. Потому что если мы сделаем FC вместо 10G, то мы получим:
а) клиента, который «just for fun» способен выжрать все ресурсы хранилища и нужно будет специально мутить с cgroups, чтобы его в этом порезать (и резать, заметим, ресурсами dom0, за которые клиент не платит).
б) Повышение цены СХД
Зачем?
Я сначала когда наткнулся на проблему «хост не может выжрать весь стор» очень переживал, оптимизировал. А потом осознал простую вещь: мне на халяву (с учётом tcp offload в сетевуху) достался мягкий и добрый шейпер, который гарантирует, что клиент не выжрет все ресурсы стора.
Существующих попугаев на виртуалку (от 3к до 8к IOPS при latency <10) я считаю более чем достаточным для того, чтобы сказать «у нас в облаке офигенная СХД». (И да, если вы меня пнёте по поводу старых аварий, мы учли ошибки, и старые хранилища имели… м… нюансы, я говорю про то, что мы начали деплоить в сентябре, и куда сейчас перенесены все клиенты, кроме одного упирающегося).
а) клиента, который «just for fun» способен выжрать все ресурсы хранилища и нужно будет специально мутить с cgroups, чтобы его в этом порезать (и резать, заметим, ресурсами dom0, за которые клиент не платит).
б) Повышение цены СХД
Зачем?
Я сначала когда наткнулся на проблему «хост не может выжрать весь стор» очень переживал, оптимизировал. А потом осознал простую вещь: мне на халяву (с учётом tcp offload в сетевуху) достался мягкий и добрый шейпер, который гарантирует, что клиент не выжрет все ресурсы стора.
Существующих попугаев на виртуалку (от 3к до 8к IOPS при latency <10) я считаю более чем достаточным для того, чтобы сказать «у нас в облаке офигенная СХД». (И да, если вы меня пнёте по поводу старых аварий, мы учли ошибки, и старые хранилища имели… м… нюансы, я говорю про то, что мы начали деплоить в сентябре, и куда сейчас перенесены все клиенты, кроме одного упирающегося).
А вот это секрет. Я не хочу, чтобы наши конкуренты повторили наш успех.
… А теперь к этому добавится хранилище, которое эти IOPS'ы выдаст в любом потребном объёме и не будет падать по очередному oops, this seems be ugly bug от Нила Брауна.
Не тираньте человека, что вы как в гестапо. Не хочет рассказывать — имеет право.Я бы на его месте тоже сперва чем хвалить и хвастать проверил бы на десять раз получившееся. А то расхвалишь, а оно пойдет валяться (все бывает, как мы знаем).
Нет такого слова «мерЯть». Мерить. Измерять.
Спасибо за статью!
Спасибо за статью!
Есть такое слово. dic.academic.ru/dic.nsf/esp_rus/98975/%D0%BC%D0%B5%D1%80%D1%8F%D1%82%D1%8C
А вот почему я выбираю тот или иной стиль при письме, то это мои уже, как автора, проблемы, правда?
А вот почему я выбираю тот или иной стиль при письме, то это мои уже, как автора, проблемы, правда?
Да, в итоге для понимания «профиля» диска/полки нужно рисовать 3-х мерный график оипсы/латентность/очередь (при заданном блоке 4к). Делал что подобное?
Увидев заголовок, почему-то вспомнились слова нашего метролога на ВУЗовской кафедре: «Меряются письками, а величины — измеряют». Мужик был весьма не глупый.
Я считаю, что это самый ценный комментарий к технической статье. Спасибо вам большое.
Если вам глаз не режет технически неграмотное употребление слов — дело ваше. Хотите — считайте, хотите — меряйте.
Почему неграмотное? Слово такое в русском языке есть. Оно разговорное, а не научно-публицистическое, но выбор словаря — это всё же выбор автора, нет?
Ровно так же использовал «попугаи» вместо «показателей». Это нарекания не вызвало?
Ровно так же использовал «попугаи» вместо «показателей». Это нарекания не вызвало?
С такой логикой можно и матами писать: слова такие есть, они разговорные, и это выбор автора. И монитор называть компьютером можно. Но так почему-то не делают. И если с попугаями все знают о чем идет речь, то именно с этим словом я уже который раз вижу, многие не совсем отчетливо понимают, какую из форм следует использовать в профессиональной речи. Я не собираюсь с кем-то спорить о том, что какие-то слова есть и каких-то нет в разговорном языке, я просто подкинул мысль, а дальше кому надо — возьмет на заметку, кому не надо — будет кричать с пеной у рта обратное и минусовать. Вы еще скажите, что поверка и проверка — одно и то же, потому что оба слова тоже есть в русском языке.
Тыг, а мы чем тут меряемся? Вот у вас сколько iops'ов?
У меня весьма маленький IOPS, так как жесткий диск довольно старый :)
(расчехляя)
test: (g=0): rw=randread, bs=4K-4K/4K-4K, ioengine=libaio, iodepth=2
fio 1.59
Starting 1 process
Jobs: 1 (f=1): [r] [100.0% done] [1248M/0K /s] [312K/0 iops] [eta 00m:00s]
test: (groupid=0, jobs=1): err= 0: pid=9600
read : io=31250MB, bw=1254.3MB/s, iops=321091 , runt= 24915msec
slat (usec): min=1 , max=110 , avg= 1.96, stdev= 0.27
clat (usec): min=3 , max=396 , avg= 3.46, stdev= 0.57
lat (usec): min=5 , max=398 , avg= 5.55, stdev= 0.62
bw (KB/s) : min=1198448, max=1319824, per=100.05%, avg=1285045.39, stdev=23648.81
cpu : usr=35.92%, sys=63.93%, ctx=43, majf=0, minf=22
IO depths : 1=0.1%, 2=100.0%, 4=0.0%, 8=0.0%, 16=0.0%, 32=0.0%, >=64=0.0%
submit : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
complete : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
issued r/w/d: total=8000000/0/0, short=0/0/0
lat (usec): 4=54.65%, 10=45.34%, 20=0.01%, 50=0.01%, 100=0.01%
lat (usec): 250=0.01%, 500=0.01%
Нихрена в этом не понимаю (ну, кроме базовых знаний в СХД). Но прочитал с большим интересом. Только вот saturation все же, скорее, «насыщение», а не некое «затенение». Инженерный же термин, вполне переводимый на русский.
Для повышения уровня знаний:
«Для HDD нет разницы запись или чтение, важно, что головки гонять по диску.»
— разница всё-таки есть — при чтении сам процесс чтения начинается раньше, когда головка над нужной дорожкой всё еще продолжает дрожать из стороны в сторону после позиционирования. При записи контроллер дожидается устаканивания головки над дорожкой. Плюс мелкая вибрация диска из вне (плохой крепеж, соседний диски, дивидюк) могут сильно снизить общую скорость записи.
«Для HDD нет разницы запись или чтение, важно, что головки гонять по диску.»
— разница всё-таки есть — при чтении сам процесс чтения начинается раньше, когда головка над нужной дорожкой всё еще продолжает дрожать из стороны в сторону после позиционирования. При записи контроллер дожидается устаканивания головки над дорожкой. Плюс мелкая вибрация диска из вне (плохой крепеж, соседний диски, дивидюк) могут сильно снизить общую скорость записи.
Ну, тут вообще можно вибрацию вспомнить, чем больше дисков — тем сильнее она влияет на себя и соседние диски.
youtu.be/tDacjrSCeq4
youtu.be/tDacjrSCeq4
Если не трудно поясните, откуда взялось то, что SSD при записи 4kb данных лопатит блок по 2мегабайта? Не ужто столь неэффективно устроено там всё?
Вот, например, статья: lwn.net/Articles/428584/ и график из неё: lwn.net/Articles/428592/
В статье про флешки (CF/DS/SDHC и т.п.), с одной стороны сказано, что все флеш-устройства работают так же, с другой в ssd могут быть какие-то исключения.
Ещё с одной стороны в четырёх разных новеньких SDHC которые я тестировал никаких скачков на 1/2/4/… мегабайтных границах нет, максимум — на 16 килобайт.
Судя по последним данным с линуксовых форумов, производители SD'шек делают хитрее. У них 4к блоки в районе FAT'а, и большие — в остальных местах.
Блин, откуда только такую инфу находите? Это получается, надо же как-то по особому ее форматировать? Или достаточно выравнивания по 4-метровым блокам?
По идее, начало ФС должно совпадать с началом первого большого erase block, и так вот как его поймать тогда?
Например, замером скорости чтения в зависимости от смещения, как на этой картинке из той же статьи.
Рассказы Intel.
Отличная статья, а каменты не менее познавательны, чем сама статья.
> Утилита весьма хитро запрятана, так что «home page» у неё просто нет, только гит-репозиторий.
# eix sys-block/fio |grep Homepage
Homepage: brick.kernel.dk/snaps/
на домашнюю страничку не тянет, зато есть все версии fio, blktrace и других утилиток
# eix sys-block/fio |grep Homepage
Homepage: brick.kernel.dk/snaps/
на домашнюю страничку не тянет, зато есть все версии fio, blktrace и других утилиток
для el6 fio можно скачать тут в rpm
yum.aclub.net/pub/linux/centos/6/umask/x86_64/fio-2.0.10-1.el6.x86_64.rpm
yum.aclub.net/pub/linux/centos/6/umask/x86_64/fio-2.0.10-1.el6.x86_64.rpm
А подскажите пожалуйста, как в fio зафиксировать формат величин в выводе результатов? А то у меня на одном сервере выводятся данные по latency в usec:
а на втором — в msec:
Конечно можно ручками пересчитать, но хотелось бы видеть разницу наглядно без калькулятора.
clat (usec): min=244, max=140717, avg=39278.48, stdev=7872.94
а на втором — в msec:
clat (msec): min=15, max=534, avg=267.07, stdev=38.65
Конечно можно ручками пересчитать, но хотелось бы видеть разницу наглядно без калькулятора.
--minimal.
А дальше удачи в парсинге вывода. Я недавно занялся вопросом, вот результат:
github.com/amarao/fio_minimal_csv_header
А дальше удачи в парсинге вывода. Я недавно занялся вопросом, вот результат:
github.com/amarao/fio_minimal_csv_header
Да, с «minimal» стало намного нагляднее ;))
Понятно, что это можно распарсить и вывести в более наглядном виде, но в целом пока устраивает текущий вывод. Т.е. в обычном выводе зафиксировать величины для вывода цифр нельзя никак?
И по поводу github.com/amarao/fio_minimal_csv_header — можете поподробнее расписать как им пользоваться? Насколько я понял, ему на вход нужно скормить вывод «fio --minimal», а на выходе он их должен оформить в каком-то более-менее приглядном виде?
# fio --minimal ./test.ini
readtest;0;0;329940;11259;30006;3;89;5.515827;1.196062;282;221438;11633.393635;33859.575791;6586;14152;102.853479%;11308.740000;2122.336812;0;0;0;0;0;0.000000;0.000000;0;0;0.000000;0.000000;0;0;0.000000%;0.000000;0.000000;0.359940%;2.266289%;82454;0;54;0.1%;0.1%;0.1%;0.1%;0.1%;100.0%;0.0%;0.00%;0.00%;0.00%;0.00%;0.00%;0.00%;0.00%;0.94%;2.62%;2.29%;9.28%;18.62%;54.01%;9.13%;0.04%;0.01%;3.06%;0.00%;0.00%;0.00%;0.00%;0.00%
writetest;0;0;0;0;0;0;0;0.000000;0.000000;0;0;0.000000;0.000000;0;0;0.000000%;0.000000;0.000000;270364;9222;30019;4;79;6.516948;1.286312;310;257231;14203.332204;37032.724029;5929;12208;102.718885%;9250.862745;1745.055266;0.199880%;2.238657%;67554;0;22;0.1%;0.1%;0.1%;0.1%;0.1%;100.0%;0.0%;0.00%;0.00%;0.00%;0.00%;0.00%;0.00%;0.00%;0.32%;2.25%;1.84%;7.67%;14.94%;44.06%;24.89%;0.29%;0.01%;3.73%;0.01%;0.00%;0.00%;0.00%;0.00%
Понятно, что это можно распарсить и вывести в более наглядном виде, но в целом пока устраивает текущий вывод. Т.е. в обычном выводе зафиксировать величины для вывода цифр нельзя никак?
И по поводу github.com/amarao/fio_minimal_csv_header — можете поподробнее расписать как им пользоваться? Насколько я понял, ему на вход нужно скормить вывод «fio --minimal», а на выходе он их должен оформить в каком-то более-менее приглядном виде?
(no Russian for now, sorry).
It do not do anything useful. It's just repository for CSV header. You should convert fio ouput from 'semicolon' to comma based (|tr ';' ',') and append header to it. After that you can open result in any table editor (Excel, Gnumeric) and see results as a table with header.
Otherwise, one can writes simple program to parse CSV output of fio to extract specific fields. They are listed in github.com/amarao/fio_minimal_csv_header/blob/master/fio_field_names.txt.
It do not do anything useful. It's just repository for CSV header. You should convert fio ouput from 'semicolon' to comma based (|tr ';' ',') and append header to it. After that you can open result in any table editor (Excel, Gnumeric) and see results as a table with header.
Otherwise, one can writes simple program to parse CSV output of fio to extract specific fields. They are listed in github.com/amarao/fio_minimal_csv_header/blob/master/fio_field_names.txt.
Наиболее частый случай, когда возникает необходимость померять производительность диска — это когда текущий проект начинает тормозить и хочется понять: станет ли ему лучше при переезде на другой сервер (речь не только о физическом железе, но и о виртуальном т.к. 2 одинаковых по параметрам VDS могут работать совершенно по-разному).
Поэтому в дополнение к статье было бы очень здорово увидеть несколько готовых конфигов к fio по разным видам нагрузке для быстрого определения производительности текущей конфигурации и сравнения с альтернативными решениями. Ну и, обязательно, с краткой инструкцией «куда смотреть» чтобы было понятно какие параметры являются ключевыми.
Например, сразу в голову приходят 4 теста:
1. Хостинг сайтов: куча мелких файлов объемом 1-500 кб, 98% конкурирующих запросов на чтение всего файла, 2% запросов на запись всего файла.
2. База данных: несколько больших файлов в несколько гб, 70% конкурирующих запросов на чтение куска файла, 30% запросов на запись куска файла.
3. Файловое хранилище: много файлов разного объема от 1 мб до нескольких гигабайт, 80% на чтение полного файла, 20% на запись полного файла.
4. Хранилище бекапов: много файлов разного объема от 1 мб до нескольких гигабайт, 5% на чтение полного файла, 95% на запись полного файла.
И, может быть, спустя 2 года с момента публикации этой статьи у вас появились какие-то дополнительные методы тестирования производительности дисков, чтобы сделать более свежую статью на эту же тему? ;)
Поэтому в дополнение к статье было бы очень здорово увидеть несколько готовых конфигов к fio по разным видам нагрузке для быстрого определения производительности текущей конфигурации и сравнения с альтернативными решениями. Ну и, обязательно, с краткой инструкцией «куда смотреть» чтобы было понятно какие параметры являются ключевыми.
Например, сразу в голову приходят 4 теста:
1. Хостинг сайтов: куча мелких файлов объемом 1-500 кб, 98% конкурирующих запросов на чтение всего файла, 2% запросов на запись всего файла.
2. База данных: несколько больших файлов в несколько гб, 70% конкурирующих запросов на чтение куска файла, 30% запросов на запись куска файла.
3. Файловое хранилище: много файлов разного объема от 1 мб до нескольких гигабайт, 80% на чтение полного файла, 20% на запись полного файла.
4. Хранилище бекапов: много файлов разного объема от 1 мб до нескольких гигабайт, 5% на чтение полного файла, 95% на запись полного файла.
И, может быть, спустя 2 года с момента публикации этой статьи у вас появились какие-то дополнительные методы тестирования производительности дисков, чтобы сделать более свежую статью на эту же тему? ;)
Кому-нибудь попадался статический бинарник fio?
с) Не забывайте обнулять диск перед тестом (т.е. dd if=/dev/zero of=/dev/sdz bs=2M oflag=direct)
с учётом засилия ssd, совет вредный. большинство ssd воспринимают это как trim, помечают у себя сектора как свободные и обращения к NAND при чтении не происходит. думаю, что многие СХД поступают так же (или хотя бы используют сжатие, что уменьшит дисковый обмен в мегабайтах в секунду и помешает нам обнаружить bus saturation).
Как раз наоборот, чем умнее контроллеры, тем важнее при бенчмарке заставить контроллеры не умничать. Вас же интересуют sustained (постоянные?) показатели производительности, а не пиковые. Для этого надо создать условия, близкие к нагрузке на 100500 день работы — т.е. запись не в "новые" блоки, а в уже давно заполненные.
К совету про обнуление я сейчас бы добавил запись рандомом, потому что вендоры не лыком шиты и любят делать трим для нулей сами.
К совету про обнуление я сейчас бы добавил запись рандомом, потому что вендоры не лыком шиты и любят делать трим для нулей сами.
так я про то и говорю, только почему добавить, а не заменить? я просто перед тестом делаю dd if=/dev/urandom of=/dev/xxx.
если уж нужно обнуление (хотя из магазина ssd обычно чистыми приходят), есть blkdiscard.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Как правильно мерять производительность диска