Пользователь
87,0
рейтинг
11 октября 2012 в 14:10

Администрирование → Как правильно мерять производительность диска tutorial

abstract: разница между текущей производительностью и производительностью теоретической; latency и IOPS, понятие независимости дисковой нагрузки; подготовка тестирования; типовые параметры тестирования; практическое copypaste howto.

Предупреждение: много букв, долго читать.

Лирика



Очень частой проблемой, является попытка понять «насколько быстрый сервер?» Среди всех тестов наиболее жалко выглядят попытки оценить производительность дисковой подсистемы. Вот ужасы, которые я видел в своей жизни:
  • научная публикация, в которой скорость кластерной FS оценивали с помощью dd (и включенным файловым кешем, то есть без опции direct)
  • использование bonnie++
  • использование iozone
  • использование пачки cp с измерениема времени выполнения
  • использование iometer с dynamo на 64-битных системах


Это всё совершенно ошибочные методы. Дальше я разберу более тонкие ошибки измерения, но в отношении этих тестов могу сказать только одно — выкиньте и не используйте.


bonnie++ и iozone меряют скорость файловой системы. Которая зависит от кеша, задумчивости ядра, удачности расположения FS на диске и т.д. Косвенно можно сказать, что если в iozone получились хорошие результаты, то это либо хороший кеш, либо дурацкий набор параметров, либо действительно быстрый диск (угадайте, какой из вариантов достался вам). bonnie++ вообще сфокусирована на операциях открытия/закрытия файлов. т.е. производительность диска она особо не тестирует.

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

С опцией же direct (iflag=direct для чтения, oflag=direct для записи) dd проверяет лишь линейную скорость. Которая совершенно не равна ни максимальной скорости (если мы про рейд на много дисков, то рейд в несколько потоков может отдавать большую скорость, чем в один), ни реальной производительности.

IOmeter — лучше всего перечисленного, но у него есть проблемы при работе в linux. 64-битная версия неправильно рассчитывает тип нагрузки и показывает заниженные результаты (для тех, кто не верит — запустите его на ramdisk).

Спойлер: правильная утилита для linux — fio. Но она требует очень вдумчивого составления теста и ещё более вдумчивого анализа результатов. Всё, что ниже — как раз подготовка теории и практические замечания по работе с fio.

Постановка задачи


(текущая VS максимальная производительность)
Сейчас будет ещё больше скучных букв. Если кого-то интересует количество попугаев на его любимой SSD'шке, ноутбучном винте и т.д. — см рецепты в конце статьи.

Все современные носители, кроме ramdisk'ов, крайне негативно относятся к случайным операциям записи. Для HDD нет разницы запись или чтение, важно, что головки гонять по диску. Для SSD же случайная операция чтения ерунда, а вот запись малым блоком приводит к copy-on-write. Минимальный размер записи — 1-2 Мб, пишут 4кб. Нужно прочитать 2Мб, заменить в них 4кб и записать обратно. В результате в SSD'шку уходит, например, 400 запросов в секундну на запись 4кб которые превращаются в чтение 800 Мб/с (!!!!) и записи их обратно. (Для ramdisk'а такая проблема могла бы быть тоже, но интрига в том, что размер «минимального блока» для DDR составляет около 128 байт, а блоки в тестах обычно 4кб, так что гранулярность DDR в тестах дисковой производительности оперативной памяти не важна).

Этот пост не про специфику разных носителей, так что возвращаемся к общей проблеме.

Мы не можем мерять запись в Мб/с. Важным является сколько перемещений головки было, и сколько случайных блоков мы потревожили на SSD. Т.е. счёт идёт на количество IO operation, а величина IO/s называется IOPS. Таким образом, когда мы меряем случайную нагрузку, мы говорим про IOPS (иногда wIOPS, rIOPS, на запись и чтение соотв.). В крупных системах используют величину kIOPS, (внимание, всегда и везде, никаких 1024) 1kIOPS = 1000 IOPS.

И вот тут многие попадают в ловушку первого рода. Они хотят знать, «сколько IOPS'ов» выдаёт диск. Или полка дисков. Или 200 серверных шкафов, набитые дисками под самые крышки.

Тут важно различать число выполненных операций (зафиксировано, что с 12:00:15 до 12:00:16 было выполнено 245790 дисковых операций — т.е. нагрузка составила 245kIOPS) и то, сколько система может выполнить операций максимум.

Число выполненых операций всегда известно и легко измерить. Но когда мы говорим про дисковую операцию, мы говорим про неё в будущем времени. «сколько операций может выполнить система?» — «каких операций?». Разные операции дают разную нагрузку на СХД. Например, если кто-то пишет случайными блоками по 1Мб, то он получит много меньше iops, чем если он будет читать последовательно блоками по 4кб.

И если в случае пришедшей нагрузки мы говорим о том, сколько было обслужено запросов «какие пришли, такие и обслужили», то в случае планирования, мы хотим знать, какие именно iops'ы будут.

Драма состоит в том, что никто не знает, какие именно запросы придут. Маленькие? Большие? Подряд? В разнобой? Будут они прочитаны из кеша или придётся идти на самое медленное место и выковыривать байтики с разных половинок диска?

Я не буду нагнетать драму дальше, скажу, что существует простой ответ:
  • Тест диска (СХД/массива) на best case (попадание в кеш, последовательные операции)
  • Тест диска на worst case. Чаще всего такие тесты планируются с знанием устройства диска. «У него кеш 64Мб? А если я сделаю размер области тестирования в 2Гб?». Жёсткий диск быстрее читает с внешней стороны диска? А если я размещу тестовую область на внутренней (ближшей к шпинделю) области, да так, чтобы проходимый головками путь был поболе? У него есть read ahead предсказание? А если я буду читать в обратном порядке? И т.д.


В результате мы получаем цифры, каждая из которых неправильная. Например: 15kIOPS и 150 IOPS.

Какая будет реальная производительность системы? Это определяется только тем, как близко будет нагрузка к хорошему и плохому концу. (Т.е. банальное «жизнь покажет»).

Чаще всего фокусируются на следующих показателях:
  1. Что best case всё-таки best. Потому что можно дооптимизироваться до такого, что best case от worst будет отличаться едва-едва. Это плохо (ну или у нас такой офигенный worst).
  2. На worst. Имея его мы можем сказать, что СХД будет работать быстрее, чем полученный показатель. Т.е. если мы получили 3000 IOPS, то мы можем смело использовать систему/диск в нагрузке «до 2000».


Ну и про размер блока. Традиционно тест идёт с размером блока в 4к. Почему? Потому что это стандартный размер блока, которым оперируют ОС при сохранении файла. Это размер страницы памяти и вообще, Очень Круглое Компьютерное Число.

Нужно понимать, что если система обрабатывает 100 IOPS с 4к блоком (worst), то она будет обрабатывать меньше при 8к блоке (не менее 50 IOPS, вероятнее всего, в районе 70-80). Ну и на 1Мб блоке мы увидим совсем другие цифры.

Всё? Нет, это было только вступление. Всё, что написано выше, более-менее общеизвестно. Нетривиальные вещи начинаются ниже.

Для начала мы рассмотрим понятие «зависимых IOPS'ов». Представим себе, что у нас приложение работает так:
  • прочитать запись
  • поменять запись
  • записать запись обратно


Для удобства будем полагать, что время обработки нулевое. Если каждый запрос на чтение и запись будет обслуживаться 1мс, сколько записей в секунду сможет обработать приложение? Правильно, 500. А если мы запустим рядом вторую копию приложения? На любой приличной системе мы получим 1000. Если мы получим значительно меньше 1000, значит мы достигли предела производительности системы. Если нет — значит, что производительность приложения с зависимыми IOPS'ами ограничивается не производительностью СХД, а двумя параметрами: latency и уровнем зависимости IOPS'ов.

Начнём с latency. Latency — время выполнения запроса, задержка перед ответом. Обычно используют величину, «средняя задержка». Более продвинутые используют медиану среди всех операций за некоторый интервал (чаще всего за 1с). Latency очень сложная для измерения величина. Связано это с тем, что на любой СХД часть запросов выполняется быстро, часть медленно, а часть может попасть в крайне неприятную ситуацию и обслуживаться в десятки раз дольше остальных.

Интригу усиливает наличие очереди запросов, в рамках которой может осуществляться переупорядочивание запросов и параллельное их исполнение. У обычного SATA'шного диска глубина очереди (NCQ) — 31, у мощных систем хранения данных может достигать нескольких тысяч. (заметим, что реальная длина очереди (число ожидающих выполнения запросов) — это параметр скорее негативный, если в очереди много запросов, то они дольше ждут, т.е. тормозят. Любой человек, стоявший в час пик в супермаркете согласится, что чем длиннее очередь, тем фиговее обслуживание.

Latency напрямую влияет на производительность последовательного приложения, пример которого приведён выше. Выше latency — ниже производительность. При 5мс максимальное число запросов — 200 шт/с, при 20мс — 50. При этом если у нас 100 запросов будут обработаны за 1мс, а 9 запросов — за 100мс, то за секунду мы получим всего 109 IOPS, при медиане в 1мс и avg (среднем) в 10мс.

Отсюда довольно трудный для понимания вывод: тип нагрузки на производительность влияет не только тем, «последовательный» он или «случайный», но и тем, как устроены приложения, использующие диск.

Пример: запуск приложения (типовая десктопная задача) практически на 100% последовательный. Прочитали приложение, прочитали список нужных библиотек, по-очереди прочитали каждую библиотеку… Именно потому на десктопах так пламенно любят SSD — у них микроскопическая задержка (микросекундная) на чтение — разумеется, любимый фотошоп или блендер запускается в десятые доли секунды.

А вот, например, работа нагруженного веб-сервера практически параллельная — каждый следующий клиент обслуживается независимо от соседнего, т.е. latency влияет только на время обслуживания каждого клиента, но не на «максимальное число клиентов». А, признаемся, что 1мс, что 10мс — для веб-сервера всё равно. (Зато не «всё равно», сколько таких параллельно запросов по 10мс можно отправить).

Трешинг. Я думаю, с этим явлением пользователи десктопов знакомы даже больше, чем сисадмины. Жуткий хруст жёсткого диска, невыразимые тормоза, «ничего не работает и всё тормозит».

По мере того, как мы начинаем забивать очередь диска (или хранилища, повторю, в контексте статьи между ними нет никакой разницы), у нас начинает резко вырастать latency. Диск работает на пределе возможностей, но входящих обращений больше, чем скорость их обслуживания. Latency начинает стремительно расти, достигая ужасающих цифр в единицы секунд (и это при том, что приложению, например, для завершения работы нужно сделать 100 операций, которые при latency в 5 мс означали полусекундную задержку...). Это состояние называется thrashing.

Вы будете удивлены, но любой диск или хранилище способны показывать БОЛЬШЕ IOPS'ов в состоянии thrashing, чем в нормальной загрузке. Причина проста: если в нормальном режиме очередь чаще всего пустая и кассир скучает, ожидая клиентов, то в условии трешинга идёт постоянное обслуживание. (Кстати, вот вам и объяснение, почему в супермаркетах любят устраивать очереди — в этом случае производительность кассиров максимальная). Правда, это сильно не нравится клиентам. И в хороших супермаркетах хранилищах такого режима стараются избегать. Если дальше начинать поднимать глубину очереди, то производительность начнёт падать из-за того, что переполняется очередь и запросы стоят в очереди чтобы встать в очередь (да-да, и порядковый номер шариковой ручкой на на руке).

И тут нас ждёт следующая частая (и очень трудно опровергаемая) ошибка тех, кто меряет производительность диска.

Контроль latency во время теста


Они говорят «у меня диск выдаёт 180 IOPS, так что если взять 10 дисков, то это будет аж 1800 IOPS». (Именно так думают плохие супермаркеты, сажая меньше кассиров, чем нужно). При этом latency оказывается запредельной — и «так жить нельзя».

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

И вот тут вот мы сталкиваемся со второй проблемой: а какого лимита? Ответить на этот вопрос теория не может — этот показатель является показателем качества обслуживания. Другими словами, каждый выбирает для себя сам.

Лично я для себя провожу тесты так, чтобы latency оставалась не более 10мс. Этот показатель я для себя считаю потолком производительности хранилища. (при этом в уме я для себя считаю, что предельный показатель, после которого начинают ощущаться лаги — это 20мс, но помните, про пример выше с 900 по 1мс и 10 по 100мс, у которого avg стала 10мс? Вот для этого я и резервирую себе +10мс на случайные всплески).

Параллелизм


Выше мы уже рассмотрели вопрос с зависимыми и независимыми IOPS'ами. Производительность зависимых Iops'ов точно контролируется latency, и этот вопрос мы уже обсудили. А вот производительность в независимых iops'ах (т.е. при параллельной нагрузке), от чего она зависит?

Ответ — от фантазии того, кто изобретал диск или конструировал хранилище. Мы можем рассуждать о числе головок, шпинделей и параллельных очередей записи в SSD, но всё это спекуляции. С точки зрения практического использования нас интересует один вопрос: СКОЛЬКО? Сколько мы можем запустить параллельных потоков нагрузки? (Не забываем про latency, т.к. если мы разрешим отправить latency в небеса, то число параллельных потоков отправится туда же, правда, не с такой скоростью). Итак, вопрос: сколько параллельных потоков мы можем выполнять при latency ниже заданного порога? Именно на этот вопрос должны отвечать тесты.

SAN и NAS


Отдельно нужно говорить про ситуацию, когда хранилище подключено к хосту через сеть с использованием TCP. О TCP нужно писать, писать, писать и ещё раз писать. Достаточно сказать, что в линуксе существует 12 разных алгоритмов контроля заторов в сети (congestion), которые предназначены для разных ситуаций. И есть около 20 параметров ядра, каждый из которых может радикальным образом повлиять на попугаи на выходе (пардон, результаты теста).

С точки зрения оценки производительности мы должны просто принять такое правило: для сетевых хранилищ тест должен осуществляться с нескольких хостов (серверов) параллельно. Тесты с одного сервера не будут тестом хранилища, а будут интегрированным тестом сети, хранилища и правильности настройки самого сервера.

bus saturation


Последний вопрос — это вопрос затенения шины. О чём речь? Если у нас ssd способна выдать 400 МБ/с, а мы её подключаем по SATA/300, то очевидно, что мы не увидим всю производительность. Причём с точки зрения latency проблема начнёт проявляться задолго до приближения к 300МБ/с, ведь каждому запросу (и ответу на него) придётся ждать своей очереди, чтобы проскочить через бутылочное горлышко SATA-кабеля.

Но бывают ситуации более забавные. Например, если у вас есть полка дисков, подключенных по SAS/300x4 (т.е. 4 линии SAS по 300МБ каждая). Вроде бы много. А если в полке 24 диска? 24*100=2400 МБ/с, а у нас есть всего 1200 (300х4).

Более того, тесты на некоторых (серверных!) материнских платах показали, что встроенные SATA-контроллеры часто бывают подключены через PCIx4, что не даёт максимально возможной скорости всех 6 SATA-разъёмов.

Повторю, главной проблемой в bus saturation является не выедание «под потолок» полосы, а увеличение latency по мере загрузки шины.

Трюки производителей


Ну и перед практическими советами, скажу про известные трюки, которые можно встретить в индустриальных хранилищах. Во-первых, если вы будете читать пустой диск, вы будете читать его из «ниоткуда». Системы достаточно умны, чтобы кормить вас нулями из тех областей диска, куда вы никогда не писали.

Во-вторых, во многих системах первая запись хуже последующих из-за всяких механизмов снапшотов, thin provision'а, дедупликации, компрессии, late allocation, sparse placement и т.д. Другими словами, тестировать следует после первичной записи.

В третьих — кеш. Если мы тестируем worst case, то нам нужно знать, как будет вести себя система когда кеш не помогает. Для этого нужно брать такой размер теста, чтобы мы гарантированно читали/писали «мимо кеша», то есть выбивались за объёмы кеша.

Кеш на запись — особая история. Он может копить все запросы на запись (последовательные и случайные) и писать их в комфортном режиме. Единственным методом worst case является «трешинг кеша», то есть посыл запросов на запись в таком объёме и так долго, чтобы write cache перестал стправляться и был вынужден писать данные не в комфортном режиме (объединяя смежные области), а скидывать случайные данные, осуществляя random writing. Добиться этого можно только с помощью многократного превышения области теста над размером кеша.

Вердикт — минимум x10 кеш (откровенно, число взято с потолка, механизма точного расчёта у меня нет).

Локальный кеш ОС


Разумеется, тест должен быть без участия локального кеша ОС, то есть нам надо запускать тест в режиме, который бы не использовал кеширование. В линуксе это опция O_DIRECT при открытии файла (или диска).

Описание теста


Итого:
1) Мы тестируем worst case — 100% размера диска, который в несколько раз больше предположительного размера кеша на хранилище. Для десктопа это всего лишь «весь диск», для индустриальных хранилищ — LUN или диск виртуальной машины размером от 1Тб и больше. (Хехе, если вы думаете, что 64Гб RAM-кеша это много...).
2) Мы ведём тест блоком в 4кб размером.
3) Мы подбираем такую глубину параллельности операций, чтобы latency оставалось в разумных пределах.

На выходе нас интересуют параметры: число IOPS, latency, глубина очереди. Если тест запускался на нескольких хостах, то показатели суммируются (iops и глубина очереди), а для latency берётся либо avg, либо max от показателей по всем хостам.

fio


Тут мы переходим к практической части. Есть утилита fio которая позволяет добиться нужного нам результата.

Нормальный режим fio подразумевает использование т.н. job-файла, т.е. конфига, который описывает как именно выглядит тест. Примеры job-файлов приведены ниже, а пока что обсудим принцип работы fio.

fio выполняет операции над указанным файлом/файлами. Вместо файла может быть указано устройство, т.е. мы можем исключить файловую систему из рассмотрения. Существует несколько режимов тестирования. Нас интересует randwrite, randread и randrw. К сожалению, randrw даёт нам зависимые iops'ы (чтение идёт после записи), так что для получения полностью независимого теста нам придётся делать две параллельные задачи — одна на чтение, вторая на запись (randread, randwrite).

И нам придётся сказать fio делать «preallocation». (см выше про трюки производителей). Дальше мы фиксируем размер блока (4к).

Ещё один параметр — метод доступа к диску. Наиболее быстрым является libaio, именно его мы и будем использовать.

Практические рецепты


Установка fio: apt-get install fio (debian/ubntu). Если что, в squeze ещё её нет.
Утилита весьма хитро запрятана, так что «home page» у неё просто нет, только гит-репозиторий. Вот одно из зеркал: freecode.com/projects/fio

При тесте диска запускать её надо от root'а.

тесты на чтение


Запуск: fio read.ini
Содержимое read.ini
[readtest]
blocksize=4k
filename=/dev/sda
rw=randread
direct=1
buffered=0
ioengine=libaio
iodepth=32

Задача подобрать такой iodepth, чтобы avg.latency была меньше 10мс.

Тесты на запись


(внимание! Ошибётесь буквой диска — останетесь без данных)
[writetest]
blocksize=4k
filename=/dev/sdz
rw=randwrite
direct=1
buffered=0
ioengine=libaio
iodepth=32

Гибридные тесты


самая вкусная часть:
(внимание! Ошибётесь буквой диска — останетесь без данных)
[readtest]
blocksize=4k
filename=/dev/sdz
rw=randread
direct=1
buffered=0
ioengine=libaio
iodepth=32
[writetest]
blocksize=4k
filename=/dev/sdz
rw=randwrite
direct=1
buffered=0
ioengine=libaio
iodepth=32


Анализ вывода


Во время теста мы видим что-то вроде такого:
Jobs: 2 (f=2): [rw] [2.8% done] [13312K/11001K /s] [3250/2686 iops] [eta 05m:12s]


В квадратных скобках — цифры IOPS'ов. Но радоваться рано — ведь нас интересует latency.

На выходе (по Ctrl-C, либо по окончании) мы получим примерно вот такое:

^C
fio: terminating on signal 2
read: (groupid=0, jobs=1): err= 0: pid=11048
  read : io=126480KB, bw=14107KB/s, iops=3526, runt=  8966msec
    slat (usec): min=3, max=432, avg= 6.19, stdev= 6.72
    clat (usec): min=387, max=208677, avg=9063.18, stdev=22736.45
    bw (KB/s) : min=10416, max=18176, per=98.74%, avg=13928.29, stdev=2414.65
  cpu          : usr=1.56%, sys=3.17%, ctx=15636, majf=0, minf=57
  IO depths    : 1=0.1%, 2=0.1%, 4=0.1%, 8=0.1%, 16=0.1%, 32=99.9%, >=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.1%, 64=0.0%, >=64=0.0%
     issued r/w: total=31620/0, short=0/0
     lat (usec): 500=0.07%, 750=0.99%, 1000=2.76%
     lat (msec): 2=16.55%, 4=35.21%, 10=35.47%, 20=3.68%, 50=0.76%
     lat (msec): 100=0.08%, 250=4.43%
write: (groupid=0, jobs=1): err= 0: pid=11050
  write: io=95280KB, bw=10630KB/s, iops=2657, runt=  8963msec
    slat (usec): min=3, max=907, avg= 7.60, stdev=11.68
    clat (usec): min=589, max=162693, avg=12028.23, stdev=25166.31
    bw (KB/s) : min= 6666, max=14304, per=100.47%, avg=10679.50, stdev=2141.46
  cpu          : usr=0.49%, sys=3.57%, ctx=12075, majf=0, minf=25
  IO depths    : 1=0.1%, 2=0.1%, 4=0.1%, 8=0.1%, 16=0.1%, 32=99.9%, >=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.1%, 64=0.0%, >=64=0.0%
     issued r/w: total=0/23820, short=0/0
     lat (usec): 750=0.03%, 1000=0.37%
     lat (msec): 2=9.04%, 4=24.53%, 10=49.72%, 20=9.56%, 50=0.82%
     lat (msec): 100=0.07%, 250=5.87%


Нас из этого интересует (в минимальном случае) следующее:
read: iops=3526 clat=9063.18 (usec), то есть 9мс.
write: iops=2657 clat=12028.23

Не путайте slat и clat. slat — это время отправки запроса (т.е. производительность дискового стека линукса), а clat — это complete latency, то есть та latency, о которой мы говорили. Легко видеть, что чтение явно производительнее записи, да и глубину я указал чрезмерную.

В том же самом примере я снижаю iodepth до 16/16 и получаю:

read 6548 iops, 2432.79usec = 2.4ms
write 5301 iops, 3005.13usec = 3ms

Очевидно, что глубина в 64 (32+32) оказалась перебором, да таким, что итоговая производительность даже упала. Глубина 32 куда более подходящий вариант для теста.

Ориентировки по производительности


Разумеется, все уже расчехляют пи… попугаемерки. Привожу значения, которые я наблюдал:
  • RAMDISK (rbd) — ~200kIOPS/0.1мс (iodepth=2)
  • SSD (intel 320ой серии) — 40k IOPS на чтение (0.8мс); около 800 IOPS на запись (после длительного времени тестирования)
  • SAS диск (15к RPM) — 180 IOPS, 9мс
  • SATA диск (7.2, WD RE) — 100 IOPS, 12мс
  • SATA WD Raptor — 140 IOPS, 12mc
  • SATA WD Green — 40 IOPS, и мне не удалось добиться latency <20 даже с iodepth=1

Предупреждение: Если вы это будете запускать на виртуальных машинах, то
а) если за IOPS'ы берут деньги — это будут весьма ощутимые деньги.
б) Если у хостера плохое хранилище, которое надеется только на кеш в несколько десятков гигабайт, то тест с большим диском (>1Тб) приведёт к… проблемам у хостера и ваших соседей по хостингу. Некоторые хостеры могут обидеться и попросить вас вон.
с) Не забывайте обнулять диск перед тестом (т.е. dd if=/dev/zero of=/dev/sdz bs=2M oflag=direct)
Георгий Шуклин @amarao
карма
268,0
рейтинг 87,0
Пользователь
Реклама помогает поддерживать и развивать наши сервисы

Подробнее
Реклама

Самое читаемое Администрирование

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

  • +1
    Точно, четко, емко — спасибо!
    Как раз будем мерить производительность хранилищ.
  • 0
    Спасибо за подробую статью!
  • +1
    Достаточно сказать, что в линуксе существует 12 разных алгоритмов контроля заторов в сети (congestion), которые предназначены для разных ситуаций. И есть около 20 параметров ядра, каждый из которых может радикальным образом повлиять на попугаи на выходе (пардон, результаты теста).

    А не подскажете, где можно об этом подробнее почитать?
    • +3
      Очень много где. Про 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
  • +8
    Вот после таких статей от amarao и его других заметок об облачных системах начинаешь понимать, что нифига не шаришь в ИТ.
    Спасибо конечно =Ъ, но низкий поклон, шаркая ножкой.
    • –4
      Надо сказать, что тут весьма поверхностно описано то, что известно любому хорошему сторадж-специалисту.
      • 0
        И много storage-специалистов знают про производительность rbd?
        • –1
          А давно рамдиски стали «стораджами»?
          • +2
            Да.
        • 0
          Про rbd интересно, кстати. В результатх фигурирует пара 200kIOPS / 0.1ms при iodepth=2, a что там происходит при увеличении iodepth?
          • +2
            Снижаются попугаи. Насколько я понимаю, на таких скоростях оверхед самого fio и стека блочных устройств линукса начинает играть более значительную роль, чем пропускная способность памяти. Почему именно 2? Полагаю, что он приводит к ситуации «один запрос обрабатывается стеком, второй в этот момент — в fio». И каждый из них может обрабатывать один запрос в один момент времени.
            • 0
              звучит логично. Спасибо.
        • 0
          Вы наверно имели в виду brd?
          На мой взгляд измерять его производительность вообще бессмысленно, потому что операции к нему как к блочному устройству никогда не завершаются. Убедитесь глядя в blktrace.
          • 0
            Хотя нет, отсутствие завершений — это проблема самого драйвера brd, который переопределяет метод постановки в очередь, в котором и выполняет чтение/запись (и, возможно, выделение страниц) синхронно, но не вызывает по окончании blk_update_request.
            • 0
              А ещё, он, гад, не апдейтит счётчики в /sys/block.
          • 0
            brd, он самый.

            Собственно, я его использовал для отладки сетевого стека — IO на него я полагал в пределах производительности СХД равным бесконечности, т.е. весь возникающий оверхед был связан с параметрами tcp, iscsi target'а и initiator'а.
    • 0
      Статья отличная, но искренне не считаю, что обладание набором таких знаний говорит о полной «прошаренности» в IT, и наоборот :)
      • 0
        Честно говоря, я вашу мысль не понял.

        Я всего лишь написал про методологию измерения производительности дисковой подсистемы, не более. Ну как бы если бы в автомобильном топике объясняли, что величина «секунд до сотни» важнее, чем «число лошадей».
        • –1
          А это он предыдущему комментатору :)
        • 0
          Ммм… vasilisc выразил мысль, что незнание тонкостей работы стораджей и облачных систем говорит о полном невежестве в IT в целом. Я позволил себе не согласиться :)
  • 0
    Есть ещё вот такая интересная ссылочка: www.802dotwhat.co.uk/how-to-calculate-storage-iops.html.
    Если пересказать кратко, то: создание RAID массива из нескольких дисков приводит к тому, что операция записи становится «дороже», вызывает более чем одну операцию ввода-вывода.

    От себя дополню, что обычно сначала считаю теоретическую производительность, затем гоняю тесты. Если теория не сходится с практикой в разы — что-то где-то настроено криво. Если сходится с погрешностью в процентов 5 — всё отлично.
    Кроме того, «как померить» — хороший вопрос. Ещё более хороший вопрос: как предсказать %)
    • 0
      кстати говоря, концовка у статьи интересная: лично наблюдаю на sata дисках по 400 iops (~380 в пике). Что в синтетических тестах, что в реальной хранилке. Что лишний раз подтверждает тезис о попугаях ;)
      • 0
        latency? Ещё раз повторяю, про latency <10 мс. Показывайте итог вывода fio и конфиг теста.

        Пока что позвольте вам не поверить, что вы с sata'шного диска можете получить 300 IOPS с 10мс latency.
        • 0
          latency померить не могу. Но она там явно выше 10мс. У меня на той хранилке вообще «всё грустно» пока.
          • 0
            Ну, понимаете, я лёгким движением руки могу сконструировать хранилище из пары десятков дисков, которое на куче тестов даст офигенные iops'ы (даже в worst case), но с latency >10с.

            Оно такое нужно?

            Это всё равно, как если бы магазин гордился, что обслуживает вместо 40 человек в час 300, но эти триста в очереди по полтора часа стоят.
    • +1
      Ну, я пока что не хотел постить на хабр, ибо она сырая, но вот утилита, которую мне пришлось написать, чтобы видеть ситуацию своими глазами: github.com/amarao/blktop (и я там всё ещё сомневаюсь в алгоритме рассчёта latency).

      Насчёт рейда — да, с некоторыми оговорками: время записи на него равно max() от времени записи на диски (т.к. все приличные рейды пишут параллельно). Наличие write-back кеша хоть какого-то размера обычно нивелирует этот аспект. Разумеется, речь про mirror'ы, для 5-6 важнее оверхед по процессору.
      • +1
        " I call it 'beta', because it's beta' than nothing" =)

        Мне чаще приходится обходиться более-менее адекватным предсказанием производительности железки. Тесты производительности мне потом несколько бесполезны: денег на изменение конфигурации всё равно не дадут. Хотя, конечно, по итоговой конфигурации мы проходимся небольшим тестом, чтобы убедиться, что конфигурация всей хранилки верна и производительность соответствует расчётной.
        • 0
          Я в основном использую для контроля latency на хостах. Её предсказывать много сложнее из-за особенностей tcp.
    • 0
      странная статейка, почему-то raid penalty зависит от типа массива, но не зависит от количества дисков в массиве.
      • +1
        Так и есть, вообще-то.
  • –1
    А под виндой SQLIO не был замечен в «неправильном» тестировании случайно?
    • +7
      Я виндами не занимаюсь.
  • 0
    Спасибо за статью, как раз собирались различные системы хранения сравнивать.
  • +1
    Если в нынешних правилах(их за последнее время слишком много, не успеваю следить) за мануалы дают деньги, то тут явно заслуженная статья.
    • +6
      Те деньги, которые Хабр предлагает за статьи — это насмешка какая-то, а не деньги. Я не писал на хабр за деньги и не планирую.
      • +1
        Да, почитал тут правила. И правда маловато )

  • 0
    Написано много и хорошо. Однако, есть небольшое но: полученные цифры не дают представления о реальной производительности будущего хранилища в вашей нагрузке. Худший случай выдал цифры, которые даже чуть выше консервативных оценок используемых при сайзинге СХД и смысла их получать кому-либо ещё и ещё раз (к чему как мне кажется статья и призывает — «вот есть такой инструмент, вот так им тестировать, тестируйте свои стораджи») — никакого. Это и так изначально известно и правильный подход к проектированию заключается в сборе требований по объёму, IOPS'ам, latency и пропускной способности, затем считается количество дисков нужного типа с учётом накладных, RAID write penalty, снапшотов, репликации на удаленные площадки и т.д.
    А реальная производительность может быть и будет выше, за счёт кеширования (в хай-энд системах вплоть до нескольких терабайт), за счёт флеш-кеширования, за счёт оптимизаций, таких как упреждающее чтение и т.д., использования алгоритмов, которые распознают паттерны нагрузки, включая такие вещи как чтение-запись-перезапись-чтение и подобное в самых разных сочетаниях встречающихся в реальных задачах.
    Опять же разные задачи требуют разных подходов — для базы данных задержка очень критична, там нужны величины порядка 1-3мс, поэтому используют техники такие как выделенные разделы кеша и отдельные рейд-группы (например, под логи — чистая последовательная запись с мгновенным требуемым откликом); для хранилища виртуальных машин VDI — нужно очень быстрое чтение небольших участков (мастер-образ); для файлового хранилища вполне пойдёт и 20мс задержки, а для бэкапного хранилища вообще без разницы, главное пропускная способность.
    • +2
      Скажите, ну вы видели хоть одного человека, который бы вам ответил без фантазий на вопрос «сколько вам нужно дисковых операций»? Я вот честно признался, что 10мс — это я с потолка взял.

      А сколько Очень Умных Интеграторов так же берут с потолка показатели «иопсов на пользователя», но не признаются в этом?
      • –4
        Очень плохо, что с потолка. Так и подмывает спросить — а остальной сайзинг вашего облака тоже с потолка?

        А для Очень Умных Интеграторов есть замеры, статистика из реальных инсталляций, сделанная как заказчиками, так и интеграторами/вендорами, есть существующие показатели производительности, бест практисы и т.д.

        • +2
          Ну вы меня улыбаете. От того, что кто-то у какого-то дяди в какой-то конфигурации померял число iops'ов не означает, что эти iops'ы можно предлагать всем остальным.

          Говорить же про «статистику реальных инсталляций» в условиях публичного облака — нонсенс.

          Завтра придёт жадный человек, который себе выставит параметры MOD в 16Мб и будет бесконечно свопиться. А послезавтра придёт человек с кеширующим в память сервером, у которого всего IO — прочитать один раз да логи с dmesg'ом писать.

          И нагрузка у них будет несопоставимая — минимум на порядок разница. Сейчас мы можем предоставить на виртуалку порядка 3-8кIOPS, но сколько человек их потребляют?

          В условиях облака вся нагрузка воспринимается как белый шум, идущий на storage. И планирование идёт именно из характеристик интегрированной нагрузки. Да даже не планирование, а простой принцип «утилизация к 50% подобралась — надо железо заказывать, чтобы к 70% его ввести в продакт».
          • –1
            > От того, что кто-то у какого-то дяди в какой-то конфигурации померял число iops'ов не означает, что эти iops'ы можно предлагать всем остальным.
            В одном случае не значит, в двух не значит, а в десяти-сотне измерений проявятся статистически значимые показатели, которые можно положить в качестве некоей базы для расчёта, разве нет?

            > Говорить же про «статистику реальных инсталляций» в условиях публичного облака — нонсенс.
            Ну вот только не надо тут этого «облачного» тумана. «Любой технарь, который попытается разобраться с технологиями, лежащими в основе «облака», после нескольких часов борьбы с потоком рекламных восторгов, обнаружит, что это облака — это те же VDSы, вид сбоку.» ©amarao. Публичное облако используется для каких-то задач, которые раньше никогда не существовали и никогда не подсчитывались в статистику? Я вас умоляю, тот же хостинг, только в профиль — раздача контента, базы данных для веба. Посчитали планируемое количество клиентов, посмотрели профиль нагрузки на аналогичные VDS'ы, помножили, заложили запас — вот и порядок величин понятен. Ну, а дальше стратегия довольно правильная — «утилизация к 50% подобралась — надо железо заказывать, чтобы к 70% его ввести в продакт».

            А в то, что «вся нагрузка воспринимается как белый шум, идущий на storage» — не верю, не может быть там белый шум, никак не может, уверен — чтение доминирует над записью, в каждой виртуалке 90% диска лежит без IOPS'ов вообще и т.д. Мнение моё, не обязательно правильное.
            • +2
              Каким образом вы планируете использовать эту базу для рассчёта? Раз на 300 пользователей CRM нужно нечто с 1000IOPS, то на 500 пользователей (другой?) CRM нужно нечто на 1500 IOPS?

              Ну вы поняли.

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

              В этих условиях пытаться предсказывать нагрузку в режиме белого ящика — это страдать фигнёй.

              Предсказываем в режиме чёрного ящика (т.е. есть график — по нему и работаем).

              Под «белым шумом» я имел в виду, что невозможно как-то разделить «вот это трафик БД, вот это трафик веб-сервера, а вот это трафик стримкастинга». Понятно, что у нас есть вполне чётко ощутимая область горячих и тёплых точек и есть огромная масса лежащих гигабайт, к которым месяцами не обращаются.

              Насчёт «чтение доминирует над записью» — нет, т.к. у виртуалок свои кеши, и чаще всего чтение хорошо закешировано со стороны клиента. (есть и обратная сторона — прошедшие операции чтения — т.к. «холодное чтение», то есть нифига не кешируемое и самое проблемное).

              Белый шум — я имел в виду, что мы не выделяем конкретных приложений. Идёт «поток», этот поток обслуживается. Все виды анализа — только статистические (и вот тут человек в комментариях подсказал blktrace, будем и его использовать), без попытки вникать в предметную область клиентов.
              • –1
                Ясно.
        • +1
          Угу, у Оракла тоже такие «бест практисы», только неизвестные им браузеры они не поддерживают.
  • 0
    Интересно, а существует ли какое-то способ проанализировать микс операций ввода-вывода, чтобы определить размер и взаимное соотношение в потоке блоков ввода-вывода, чтобы получить на выходе что-то «гистограммное»: за час операций блоками 4K — 73% IO, блоками 64K — 8%, блоками 512b — 6%, и так далее?
    • +1
      У меня давно чешутся руки написать что-то типа dm_log, который бы представлял из себя device mapper устройство, которое бы просто писало лог операций с таймстемпами, пропуская реальные данные дальше вниз по стеку. Т.е. на выходе мы имели бы лог с данными о том, когда, куда и сколько писали. А на него уже можно было бы натравливать всякие R для поиска закономерностей…

      Увы, это всё фантазии.
      • 0
        Ну собственно что-то такое я себе и представлял. Неужели до сих пор не написано? Ведь соотношение блоков в workload это ключевой аспект при измерении и оценке производительности.
        • 0
          Можно оценить попадание в кеш (например, flashcache даёт достаточно статистики, чтобы это увидеть). А вот распределение по частоте попадания в блоки… Увы, я такого не видел.
      • +4
        Такая штука уже есть, называется blktrace
        • 0
          Спасибо.
    • 0
      Где-то я такое видел, в анализаторе производительности какого-то стораджа что ли.
  • 0
    Большое спасибо за статью — очень ко времени.
    В качестве тестов(параллельно с fio) используем еще нагрузку ORION Oralcle, утилита бесплатна и предоставляет различные варианты операций с дисками, ну и предполагает эмуляцию работы БД(Oracle'овой как минимум). Есть ли у вас опыт работы с этим тестом — интересно мнение?
    • 0
      Я с Ораклом не работал, и надеюсь, что не буду. Ключевые моменты для проверки: можно ли там запустить чтение независимо от записи? Показывает ли оно latency? Умеет ли O_DIRECT?
      • 0
        Промахнулся, ответ ниже по ветке.
  • 0
    Да, в тесте можно запускать отдельно RR/RW; SR/SW; определять количество тредов, размеры блоков, имитация рейдов… и да, Latency показывает, для нас это тоже ключевой момент. Про работу без кеша сказать точно не могу.
    • +1
      Ну, если убрать такое сомнительное преимущество как «оно написано ораклом», то у fio есть сырцы, да и употребляется он чаще. Если же отдаться в рабство работать с ораклом, то его утилиты юзать надо, ибо они лучше других знают про паттерны нагрузки своей субд.

      В условиях же случайной и заранее неизвестной нагрузки, лучше работать с тестами worst case.
  • –1
    Очень вовремя как раз меряю IOPS-ы на амазоновских EBS дисках. Как раз все перепробовал из верхнего списка ПО, а вот до fio еще не дошел как раз
  • 0
    Просто из любопытства спрошу — а зачем изобретать велосипед, если есть www.storageperformance.org с вполне себе оформившейся и устоявшейся методологией? Бери и пользуйся.
    • 0
      Там тестируют всякие непонятные штуки, типа транзакционных баз данных и все такое, это не показывает «настоящей, 4к 100%random» производительности.
  • 0
    Ты забыл про spew.
    • 0
      ЗЫ и, имхо, глубину очереди вскользь как-то описал. могут не понять.
      • 0
        В смысле? Очередь имеет очень простые последствия: чем больше допустимая очередь, тем больше попугаев. Чем больше реальная длина очереди, тем выше утилизация хранилища и тем хуже latency обслуживаемой задачи.
        • 0
          Ты в статье это (имхо) недостаточно доступно описал. У меня то проблем с пониманием нет.
    • 0
      Почитал man к ней, откровенно не понял, в чём прелесть. Нет возможности пустить задачи в параллель (т.е. чтение всегда зависимо от записи). В третьих из rw там только read after write, т.е. сплошное хождение по кешу. А можно мне так, чтобы оно писало рандомом и при этом читало с других мест? А в несколько потоков?

      Плюс я не увидел у него latency в выводе, т.е. смысла в этой утилите никакого.

      Что можно сказать про диск, у которого вот такие попугаи:
      RTR: 2091.45 KiB/s Transfer time: 00:00:31 IOPS: 522.86
      • 0
        сложно сказать, так как service time (latency) не указан… Вообще, 522 IOPS очень странная цифра… для одного диска многовато. Это raid ил 2-3 дисков? Либо много кеш хитов
        • 0
          Это тот самый WD Green, который в fio показал 50-90 IOPS, при латенси от 20 до 1000мс :)

          Я к тому, что утилита явно меряет что-то у кьюриосити, вместо того, чтобы производительность диска смотреть.
      • 0
        Это странно слышать от тебя «почитал ман», не далее как два года назад и ты, и я отлично мерили иопсы дисков именно ей. (гули spew по своему и моему жж).
        В параллель — да, нету.
        Чтение после записи — ну если размер тестируемой области достаточно большой, кеши можно пробить.
        Латентность я смотрел отдельно системными утилитами, да, не так удобно, но количественные показатели можно понять.
        • +2
          Полистал. Да, был неопытным, даже нашёл fio, но пропустил, не поняв всей её прелести. spew настолько забыл, что вот, пришлось вспоминать с нуля.

          Без latency ни один тест не интересен. Потому что тот же wd green аж под 90 IOPS выдаёт.… При latency в 500мс.

          Сейчас, когда я на эту тему два года потратил, я могу сказать, что fio реализует 90% нужного функционала.

          Я бы не отказался от функции «мерять число IOPS'ов при фиксированной latency», то есть автоматический подбор числа iodepth, но даже без этого оно неплохо.

          Вторая претензия к fio — немного неровный рандом, который явно задирает производительность к концу теста.
          • 0
            Да нет, ты меня уже убедил в правильности fio, я уже пару месяцев ей тыкаю свою помойку.

            Вот я потому и пишу, что надо график от латентности строить (собственно я это говорил еще два года назад, но у меня не было средств/желания/времени такое соорудить). тогда будет видно, какие iops мы можем получить в хорошей области (до 10, до 20 мс), а какие за пределами.
            • +1
              Типа таких графики нужны:
              image
              • +1
                Выглядит ркуто. Это кто так мило делает и на ком? судя по стартовой точке это на магнитных дисках.
                • +2
                  Этот конкретный график — это из тестирования SPC-1 СХД 3par, взял у romx тут .
                  • +1
                    Сколько шпинделей? Цена?
                    • +1
                      Там по ссылке всё есть :)
                      • +3
                        А теперь давайте считать вместе экономику этого 3par.

                        1920 дисков в 6/60ом рейде с хотспарами будет примерно (утрирую) 1700 дисков полезных. Итого 1728*146=252Тб.

                        По нашим ценам это будет приносить 4.5р*252=1134р/час. То есть примерно 9.9 миллиона в год. При полной загрузке. Стоимость железки 174 миллиона. Итого — 17 лет окупаемости.

                        Я, конечно, лукавлю, IOPS'ы вполне приносят деньги. Но даже если мы утроим годовую выручку, всё равно это нерентабельно. (А ещё надо не забывать про клиентов, которые «положили диск и забыли», т.е. IO не генерируют).

                        Рынок IaaS уже достаточно сформировавшийся, чтобы цены на нём диктовались не себестоимостью.

                        И указанное решение в эту цену не укладывается.
                        • 0
                          Погоди, ты считаешь доход по объёму, а затраты по производительности (так как система за 170млн набита самыми маленькими дисками и кучей контроллеров только ради того, чтобы максимум iops'ов снять). С таким подходом конечно будет не рентабельно. Да и вообще я не предлагаю подобное решение, просто график привел красивый.
                          • 0
                            С IOPS'ами в публичном облаке всё ещё забавнее: их нужно много, но есть некий показатель IOPS/Гб, выше которого не имеет смысла гнать производительность — никто оплачивать её не будет.
                        • 0
                          И ещё — если смотреть тот же Нетапп, который в отчете есть, то получится другая экономика: 171Тб за 50млн (это лист-прайс причём, со скидкой и в два-три раза дешевле может быть) и получается окупаемость 7,5лет, а по нормальной цене (со скидкой) — 2.5-3.5г, что вполне себе нормально (и это мы всё ещё смотрим хранилище оптимизированное по iops'ам, а доход по объёму).
                          • 0
                            И оно всё ещё выходит за рамки планируемой окупаемости. В стоимости услуги нужно ещё учитывать размещение в ДЦ (оно нам сам себе всё ж не бесплатное), так что 3 года возврата в виде выручки для железа — слишком большой срок.
                    • 0
                      5 885 148$
                      «1920 дисков 146GB 15K RPM»

                      и этому противопоставляется
                      нетапп с
                      «432 диска 450GB 15K RPM».
                      • 0
                        Ага, за $1 672 602
                        • 0
                          Думаю, что самосбор, даже с учетом резервирования, обходится заметно дешевле.
                          • –1
                            И где этот мифический дешевый самосбор? Киньте ссылку на систему показывающую аналогичный результат SPC-1? Ну, и раз даже сам amarao фактически ушёл от самосбора в качестве стораджа (хотя и кокетливо не признаётся на что именно), то видимо цена не самый главный фактор? Мы ведь её заложим в стоимость услуг, да и всё.
                            • 0
                              Мне кажется, что не ушел.
                              Цена для такой демпинговой услуги — очень важна. И если они будут покупать готовые сторы — у них взлетит или единомоментно цена на диск в облаке (причем сразу раз в 10-20), или уменьшится время окупаемости — а это не интересно инвесторам.
                              • 0
                                Мне кажется вы с ним давно знакомы и оба из Питера :) Можешь расспросить при случае, глядишь признается.
                                • 0
                                  Мне кажется, я более-менее представляю, просто не могу рассказывать то, что он сам не решил говорить публично.
                            • 0
                              Если вы мне расскажите, как оный SPC-1 запускать, запущу. У них на сайте как-то совсем невнятно и без ссылки на сырцы/бинарник.
                              • 0
                                SPC-1 в «коробочном виде» стоит денег, довольно больших, как я знаю.
                                Но существует довольно подробное «описание словами», по которому, при T -> бесконечность можно попробовать его реверсинжинирить.
                                Или, по крайней мере, взять из него полезное относительно workload. Это конечно не будет бенчмарком SPC-1, в смысле полученными результатами нельзя будет меряться с результатами официального SPC-1, но внутри себя — как вариант.
                                • 0
                                  Внутри себя я вполне определился с fio. Можно, конечно, колдовать над параметрами, но понятно, что любое отклонение от чистого рандома будет давать лучшие результаты. Так что при планировании вполне можно опираться на worst case, который я вижу.
                            • 0
                              У нас сейчас нет такого количества шпинделей.

                              В среднем одна коробочка (4U) показывает примерно 6-10к IOPS.
                              • 0
                                Это чисто с дисков. А если выстреливают кеши (а они довольно часто выстреливают) то там иопсов получается заметно больше.
          • +1
            Я бы не отказался от функции «мерять число 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
            
            • 0
              Спасибо. Я её давно видел, но запустить не получалось. После того, как задал window/percentile, заработало.
  • 0
    В копилку: Oracle Compilebench. Эмулирует нагрузку на файловую систему, сильно похожую на компиляцию ядра линукса. Очень полезно для тестирования подобного паттерна нагрузки и для тестирования верхнего уровня — файловой системы.
  • 0
    Статья хороша, но ведь людям иногда нужна банальность, простой линейный тест чтения/записи, ибо не все производители делают винты так чтобы они справлялись как раз в том самом узком горлышке, а именно SATA/SAS/ATA (начиная от того момента как пользователь захотел отправить поток данных и как этот поток прошел через все контроллеры, шлейфы(а может и оптика или медь) и невесь как попало на винт, вот иногда важно ведь знать сможет прожевать интерфейс, или заткнется где нибудь по пути… В общем я считаю dd приминимо, но в своих целях.
    • +2
      dd (c iflag=direct) используется в основном для проверки «оно там вообще живо или нет?». Ничего осмысленного из цифр dd для себя сказать нельзя.

      Собственно — у нас хранилище выдаёт примерно 50-80Мб/с на виртуалку при 4-8к IOPS (latency <10), рядом у меня лежит WD green, который выдаёт 110Мб/с при 40 IOPS и latency >20. Кто из них быстрее?
    • +1
      «Прямой линейный тест чтения-записи» строго говоря нужен только для одного — для бэкапа (ну, ОК, еще для DSS-баз, возможно). А это все же довольно частная и узкая задача, совершенно не массовая.
      • 0
        Внезапно: если на СХД приходит большая нагрузка, то вроде бы линейный бэкап превращается в +100500 к random IO.

        PS NL-storage (write once, read rare) отдельный мир. Я с ним в продакте не имел дела, по своей домашней коллекции, о которой я думаю, там ключевым фактором является надёжность, цена, энергопотребление и время первого доступа.
        • 0
          Если выделить под бекап отдельную рейд-группу и партишн кеша, то линейный бэкап останется линейным, а остальная рандомная нагрузка останется как была.
          • 0
            Возможно, мы по терминологии не понимаем друг друга.

            Я говорю: если делать бэкап LUN'а, который сильно занят, то для него процесс чтения (вроде бы линейный) будет мало отличаться от рандомного IO, т.к. в очереди будет дофига других запросов.
            • 0
              А, в этом плане да. Я имел в виду то место куда делается бэкап.
              • 0
                Если речь про большие данные, то бэкапирующая система — чистой воды NL-storage, то есть write once, read rare. IOPS'ы почти не важны, важна линейная скорость, цена за гигабайт и стоимость (электричества) на время «стоять и хранить».
            • +1
              Выше я говорил скорее про то, что, в real life показатели секвентального чтения-записи не интересны почти совсем, отчасти потому что это очень узкий набор задач, который юзает sequental, отчасти вот из-за микса, в котором сегодня рандом преобладает по определению многозачачных систем.
              Потому и непонятно отчего все еще «копирование BD-рипа в Тоталкоммандере» все еще (часто) используется в качестве измерения параметра диска.
  • 0
    Автор вроде все расписал, а чего-то не хватает. А именно:
    — ничего не сказано про такой параметр как утилизация дисков. В случае если мы говорим об отдельном диске — это легко меряется. Например вот тут, слайды 12-15
    www.ruoug.org/events/20091111/perf_IO_presentation.pdf
    — про SAN/ NAS ни разу не надо тестить с нескольких серверов. Один сервер запросто генерит такую нагрузку чтобы напрочь убить любую дисковую подсистему. Характер нагрузки при этом легко настраивается увеличением числа параллельных потоков.
    • 0
      У нас SAN — 10G. Одиночный хост на стор давал около 15кIOPS по одному TCP-линку. Когда я рядом поставил второй хост, каждый из них давал 15кIOPS. Потом я поставил все хосты из лаборатории (6шт) — и получил по 15к на каждый.

      Утилизация на сторе росла, общая латенси тоже, но всё в пределах нормы (т.е. latency <10мс). Когда я начал играться с TCP, я добился, что единичный хост стал выжимать до 36к IOPS, но это был потолок (потом я подумал и вернул обратно — 15к на хост выглядит более чем разумно).

      Если вы думаете, что единичный сервер может положить любую дисковую подсистему — добро пожаловать к нам в облако. За ваши деньги — неограниченные IOPS'ы. Заметим, без затруднений для клиентов вокруг.
      • +1
        Подождите, откуда TCP в SAN? Вы кажется путаете SAN (Fibre channel) c чем-то еще.

        Спасибо, за предложение, но у меня есть собственный опыт на эту тему. Обычный proliant с двумя 4GB карточками запросто генерит 60,000 IOPS, и это далеко не предел, так как мы уперлись на стороне массива.

        По поводу вашего теста, надо смотреть детали. Я не уверен какой массив вы тестировали, но видимо какой-то большой.
        То есть чтобы давать 36k IOPS при ~120 IOPS/диск вам нужно ~ 300 физических дисков.
        • +2
          SAN — это любая storage area network. А FC там, инфинибэнд или 10G — нет никакой разницы.
        • 0
          Всё нормально, FC — это слишком сурово для мира облаков на линуксе, там всё из коробки оптимизировано под задачи хранения и нет "12 разных алгоритмов контроля заторов в сети (congestion), которые предназначены для разных ситуаций. И есть около 20 параметров ядра, каждый из которых может радикальным образом повлиять на попугаи".
          • 0
            FC это слишком сурово для публичных облаков. Потому что если мы сделаем FC вместо 10G, то мы получим:
            а) клиента, который «just for fun» способен выжрать все ресурсы хранилища и нужно будет специально мутить с cgroups, чтобы его в этом порезать (и резать, заметим, ресурсами dom0, за которые клиент не платит).
            б) Повышение цены СХД

            Зачем?

            Я сначала когда наткнулся на проблему «хост не может выжрать весь стор» очень переживал, оптимизировал. А потом осознал простую вещь: мне на халяву (с учётом tcp offload в сетевуху) достался мягкий и добрый шейпер, который гарантирует, что клиент не выжрет все ресурсы стора.

            Существующих попугаев на виртуалку (от 3к до 8к IOPS при latency <10) я считаю более чем достаточным для того, чтобы сказать «у нас в облаке офигенная СХД». (И да, если вы меня пнёте по поводу старых аварий, мы учли ошибки, и старые хранилища имели… м… нюансы, я говорю про то, что мы начали деплоить в сентябре, и куда сейчас перенесены все клиенты, кроме одного упирающегося).
            • 0
              Вот мне интересно на что в итоге перенесли-то? Промышленная СХД какая-то или всё те же поделки на базе серверов, только новые?
              • 0
                А вот это секрет. Я не хочу, чтобы наши конкуренты повторили наш успех.
                • 0
                  Да ладно вам =) Ваш успех в правильном аккаунтинге ведь был, разве нет?
                  • 0
                    … А теперь к этому добавится хранилище, которое эти IOPS'ы выдаст в любом потребном объёме и не будет падать по очередному oops, this seems be ugly bug от Нила Брауна.
                  • –1
                    Не тираньте человека, что вы как в гестапо. Не хочет рассказывать — имеет право.Я бы на его месте тоже сперва чем хвалить и хвастать проверил бы на десять раз получившееся. А то расхвалишь, а оно пойдет валяться (все бывает, как мы знаем).
                    • 0
                      Да я и не тираню, просто слегка подтруниваю. Будет возможность и желание — расскажет.
  • 0
    Нет такого слова «мерЯть». Мерить. Измерять.
    Спасибо за статью!
  • 0
    Да, в итоге для понимания «профиля» диска/полки нужно рисовать 3-х мерный график оипсы/латентность/очередь (при заданном блоке 4к). Делал что подобное?
    • 0
      Честно говоря, нет. Меня вполне устраивает срез по ожидаемому качеству сервиса (т.е. 10мс latency), ну, может быть, ещё срезы на 5, 20 и 50 мс.
  • –5
    Увидев заголовок, почему-то вспомнились слова нашего метролога на ВУЗовской кафедре: «Меряются письками, а величины — измеряют». Мужик был весьма не глупый.
    • +1
      Я считаю, что это самый ценный комментарий к технической статье. Спасибо вам большое.
      • –1
        Если вам глаз не режет технически неграмотное употребление слов — дело ваше. Хотите — считайте, хотите — меряйте.
        • +1
          Почему неграмотное? Слово такое в русском языке есть. Оно разговорное, а не научно-публицистическое, но выбор словаря — это всё же выбор автора, нет?

          Ровно так же использовал «попугаи» вместо «показателей». Это нарекания не вызвало?
          • –3
            С такой логикой можно и матами писать: слова такие есть, они разговорные, и это выбор автора. И монитор называть компьютером можно. Но так почему-то не делают. И если с попугаями все знают о чем идет речь, то именно с этим словом я уже который раз вижу, многие не совсем отчетливо понимают, какую из форм следует использовать в профессиональной речи. Я не собираюсь с кем-то спорить о том, что какие-то слова есть и каких-то нет в разговорном языке, я просто подкинул мысль, а дальше кому надо — возьмет на заметку, кому не надо — будет кричать с пеной у рта обратное и минусовать. Вы еще скажите, что поверка и проверка — одно и то же, потому что оба слова тоже есть в русском языке.
    • +1
      Тыг, а мы чем тут меряемся? Вот у вас сколько iops'ов?
      • 0
        У меня весьма маленький IOPS, так как жесткий диск довольно старый :)
        • +1
          (расчехляя)
          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%
          
  • 0
    Нихрена в этом не понимаю (ну, кроме базовых знаний в СХД). Но прочитал с большим интересом. Только вот saturation все же, скорее, «насыщение», а не некое «затенение». Инженерный же термин, вполне переводимый на русский.
    • 0
      Наверное. Я вообще в русской литературе bus saturation не встречал.
      • 0
        А в фотошопе/гимпе? :)
  • 0
    Для повышения уровня знаний:
    «Для HDD нет разницы запись или чтение, важно, что головки гонять по диску.»
    — разница всё-таки есть — при чтении сам процесс чтения начинается раньше, когда головка над нужной дорожкой всё еще продолжает дрожать из стороны в сторону после позиционирования. При записи контроллер дожидается устаканивания головки над дорожкой. Плюс мелкая вибрация диска из вне (плохой крепеж, соседний диски, дивидюк) могут сильно снизить общую скорость записи.
    • +1
      Ну, тут вообще можно вибрацию вспомнить, чем больше дисков — тем сильнее она влияет на себя и соседние диски.
      youtu.be/tDacjrSCeq4
  • 0
    Если не трудно поясните, откуда взялось то, что SSD при записи 4kb данных лопатит блок по 2мегабайта? Не ужто столь неэффективно устроено там всё?
    • 0
      Вот, например, статья: lwn.net/Articles/428584/ и график из неё: lwn.net/Articles/428592/
      • 0
        В статье про флешки (CF/DS/SDHC и т.п.), с одной стороны сказано, что все флеш-устройства работают так же, с другой в ssd могут быть какие-то исключения.
        • 0
          Ещё с одной стороны в четырёх разных новеньких SDHC которые я тестировал никаких скачков на 1/2/4/… мегабайтных границах нет, максимум — на 16 килобайт.
          • 0
            Каким образом тестировали? Как это вообще можно узнать?
            • 0
              flashbench, что в статье по ссылке.
        • 0
          Судя по последним данным с линуксовых форумов, производители SD'шек делают хитрее. У них 4к блоки в районе FAT'а, и большие — в остальных местах.
          • 0
            Блин, откуда только такую инфу находите? Это получается, надо же как-то по особому ее форматировать? Или достаточно выравнивания по 4-метровым блокам?
            • 0
              Да не парьтесь вы, работает и ладно, вам что так принципиально что у них там внутрях?
              • +2
                похоже, что вы не инженер.
                • 0
                  Наоборот =) Именно это и не даёт мне париться по поводу «особо форматирования флешек».
          • 0
            По идее, начало ФС должно совпадать с началом первого большого erase block, и так вот как его поймать тогда?
            • 0
              Например, замером скорости чтения в зависимости от смещения, как на этой картинке из той же статьи.
    • 0
      Рассказы Intel.
  • 0
    Отличная статья, а каменты не менее познавательны, чем сама статья.
  • 0
    > Утилита весьма хитро запрятана, так что «home page» у неё просто нет, только гит-репозиторий.
    # eix sys-block/fio |grep Homepage
    Homepage: brick.kernel.dk/snaps/

    на домашнюю страничку не тянет, зато есть все версии fio, blktrace и других утилиток
  • 0
    для el6 fio можно скачать тут в rpm
    yum.aclub.net/pub/linux/centos/6/umask/x86_64/fio-2.0.10-1.el6.x86_64.rpm
  • 0
    А подскажите пожалуйста, как в fio зафиксировать формат величин в выводе результатов? А то у меня на одном сервере выводятся данные по latency в usec:
        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
    

    Конечно можно ручками пересчитать, но хотелось бы видеть разницу наглядно без калькулятора.
    • 0
      --minimal.

      А дальше удачи в парсинге вывода. Я недавно занялся вопросом, вот результат:

      github.com/amarao/fio_minimal_csv_header
      • 0
        Да, с «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», а на выходе он их должен оформить в каком-то более-менее приглядном виде?
        • 0
          (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.
  • 0
    Наиболее частый случай, когда возникает необходимость померять производительность диска — это когда текущий проект начинает тормозить и хочется понять: станет ли ему лучше при переезде на другой сервер (речь не только о физическом железе, но и о виртуальном т.к. 2 одинаковых по параметрам VDS могут работать совершенно по-разному).

    Поэтому в дополнение к статье было бы очень здорово увидеть несколько готовых конфигов к fio по разным видам нагрузке для быстрого определения производительности текущей конфигурации и сравнения с альтернативными решениями. Ну и, обязательно, с краткой инструкцией «куда смотреть» чтобы было понятно какие параметры являются ключевыми.

    Например, сразу в голову приходят 4 теста:

    1. Хостинг сайтов: куча мелких файлов объемом 1-500 кб, 98% конкурирующих запросов на чтение всего файла, 2% запросов на запись всего файла.

    2. База данных: несколько больших файлов в несколько гб, 70% конкурирующих запросов на чтение куска файла, 30% запросов на запись куска файла.

    3. Файловое хранилище: много файлов разного объема от 1 мб до нескольких гигабайт, 80% на чтение полного файла, 20% на запись полного файла.

    4. Хранилище бекапов: много файлов разного объема от 1 мб до нескольких гигабайт, 5% на чтение полного файла, 95% на запись полного файла.

    И, может быть, спустя 2 года с момента публикации этой статьи у вас появились какие-то дополнительные методы тестирования производительности дисков, чтобы сделать более свежую статью на эту же тему? ;)

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