какая единица измерений используется для обозначения скорости жесткого диска
Какая единица измерений используется для обозначения скорости жесткого диска
Приветствую все, уважаемые читатели и посетители. 🙂
Продолжаем серию заметок о жестких дисках, и сегодня мне бы хотелось обратить внимание на такой параметр HDD, как скорость вращения шпинделя, на который насажены собственно пластины с данными. Важен ли этот параметр?
Жесткий диск — это сложное электромеханическое устройство. Оно сочетает в себе механическую и электронную часть. Механика обеспечивает вращение диска или пакета дисков (если жесткий диск построен на нескольких пластинах — как правило это диски большой емкости), обеспечивает сверхточное позиционирование головки над пластинами…Электроника — считывает, записывает и изменяет данные на диске непрерывно с очень большой скоростью.
Эти две составляющие должны работать слаженно и быть максимально надежными. В большей степени надежность зависит от механической части — примерно 80-90 процентов.
Один из главных составляющих механики диска — двигатель. Он должен обладать обязательным параметром — способностью очень долго поддерживать фиксированное число оборотов шпинделя.
Шпиндель должен вращаться заданное число оборотов. На сегодня есть несколько типов дисков, если смотреть на количество оборотов пластин:
5400 об/мин — В основном используются в ноутбуках, т.к. число оборотов низкое — значит выше надежность и ниже энергопотребление. А это критично для ноутбуков. Еще встречаются в настольных ПК в так называемых «зеленых» (экологичных) жестких дисках, которых отличает рекордно низкое потребление энергии.
7200 об/мин — 90% всех жестких дисков. Используются в основном в настольных ПК — они не критичны к потреблению энергии и им нужна высокая производительность. А производительность тем больше, чем больше оборотов делает шпиндель (это один из факторов). Можно сказать это золотая середина между скоростью и надежностью.
10 или 15 000 об/мин — Самые производительные диски, но и самые ненадежные… Высокое число оборотов приводит к сильному нагреву пластины — при этом угроза потери данных просто огромна! Ну и конечно — механический износ… Этот фактор, как говорится, никто не отменял. 😉
Итак, самыми приемлемыми на сегодня можно назвать диски с частотой вращения пластин 7200 оборотов в минуту. Нагрев приемлемый, и производительность выше, чем у дисков 5400 об/мин. Да и цена приемлемая. Высокооборотистые диски как правило очень дороги, а прирост производительности себя совершенно не оправдывает, из-за низкой надежности носителя.
А кому нужен жесткий диск, на котором опасно хранить информацию?
P.S. Напоминаю Вам, что очень скоро стартует мой новый проект, который целиком и полностью будет посвящен такому важному вопросу, как информационная безопасность. Подробности: www.oborona.info-dvd.ru.
Устройство и типы жёстких дисков
Как было сказано выше, жёсткий диск предназначен для постоянного хранения информации, и отличие его памяти от ОЗУ в том, что она энергонезависима – то есть сохраняется на носителе при отключении питания. Жёсткий диск представляет собой электромеханическое устройство, то есть имеет движущиеся детали, и состоит из нескольких основных частей.
Это интегральная схема, которая управляет процессами записи/чтения и работой диска. Она устанавливается поверх основного корпуса диска. В самом же корпусе спрятано сердце винчестера, состоящее из шпинделя (электромотора), который вращает диск; считывающей головки (коромысла), которое подвижно и считывает информацию непосредственно с поверхности носителя, и самих магнитных дисков памяти (их может быть разное количество, располагаются они один над другим, слоями).
На рынке сейчас распространены три типа жёстких дисков:
· HDD – жёсткий магнитный диск
· SSHD – гибридный жёстки диск, с небольшим объёмом твердотельной флэш-памяти (вернёмся к этому типу позже)
· SSD– полностью твердотельный диск
SSD диски пока достаточно дороги, но выигрывают у HDD в скорости, SSHD – компромисс между твердотельными носителями и магнитными. Если обобщить общие преимущества и недостатки HDD по сравнению с SSD, то получим следующий список.
Преимущества HDD
· Стоимость — HDD диск 3.5” того же объёма обойдётся вам в 3-4 раза дешевле SSD
· Объём – HDD формат может похвастаться моделями в 4, 6, 8, 10 ТБ, в то время как SSD достигают пока объёма в 1-2 ТБ, при этом имея заоблачный ценник
· Высокий ресурс – нет ограничения циклов перезаписи, жёсткий диск скорее выработает свой механический ресурс (заявленное время наработки на отказ у некоторых моделей доходит до 1 млн. часов)
· Возможность восстановить данные с неисправного диска – довольно важная особенность: пригождается редко, но бывает жизненно важна
Гибридные жёсткие диски SSHD
Гибридный жёсткий диск, или SSHD, это простой магнитный жёстки диск, к которому добавлен небольшой объём флэш-памяти. В большинстве моделей это 8 ГБ. Немного, если сравнить с полноценным SSD.
Эта добавленная флэш-память служит в качестве кэша для диска, — вся информация, к которой обращения происходят часто, автоматически записывается именно во флэш-память, что многократно ускоряет доступ к ней. Принцип работы следующий: при обращении к диску информация сначала ищется в самом быстром кэше 1-го уровня (от 16 до 256 МБ, есть у каждого HDD), а после – в кэше 2-го уровня, которым и является твердотельная добавка в 8 ГБ.
Гибридный жёсткий диск не поможет вам загрузить быстрее операционную систему, поскольку флэш-память начинает работать только после загрузки системы, но работу с программами ускорит заметно. Также разница в максимальной скорости передачи файлов с обычным HDD будет невелика – порядка 15%, но вот скорость доступа к файлам может отличаться в десятки раз.
SSHD – это хороший выбор для домашнего медиа-диска, если вы хотите повысить общую скорость работы при большом объёме накопителя, и если скорость для вас важна, но не критична. Пожалуй, лучший выбор из магнитных жёстких дисков. Хотя и минусы тоже есть – цена на SSHD почти вдвое выше, и очень мало моделей поддерживает оптимизацию под RAID-массив (хотя в этом у рядового пользователя редкая необходимость).
Какого объёма кэша хватит?
Речь идёт о объёме кэша 1-го уровня – его величина может колебаться, можно встретить модели с объёмами от 16 до 256 МБ. Это высокоскоростная флэш-память, которая ускоряет работу жёсткого диска, но это ускорение незначительно (порядка 5-10%), и происходит не для всех операций. Например, при последовательном чтении с диска или переносе больших файлов разница в кэше заметна не будет.
Не стоит гнаться за максимальным значением данного параметра – эффективность работы кэша зависит больше от алгоритмов работы кэше, чем от его объёма, к тому же производители стараются для каждой модели подобрать максимально подходящий размер кэша.
Также объём кэша зависит от общей ёмкости жёсткого диска – для моделей до 500 ГБ стоит ориентироваться на 16 Мб кэша, при объёме до 2 ТБ кэш обычно составляет 32-64 МБ. Модели с кэшем 64 МБ и меньше при объёме диска больше 2 ТБ могут оказаться не самыми быстрыми вариантами, стоит это учитывать.
Для объёма диска 2 ТБ и более стандартный объём кэша – 128 МБ, причём для объёмов в 6-10 ТБ предпочтительней, естественно, кэш 256 МБ.
Хотя сам параметр кэша и не очень критичен для скорости работы HDD, но при небольшой разнице в стоимости лучше рассматривать модель с большим объёмом.
Скорость вращения шпинделя – 5400 или 7200?
Один из главных параметров жёсткого диска, непосредственно влияющий на скорость работы: чем физически быстрее считывающая головка окажется в нужной позиции, тем быстрее произойдёт чтение/запись. На сегодняшний день существует средний разброс по скорости стандартных HDD – от 5400 до 7200 об/м. Есть также диски с оборотами в 10 000 об/мин и более, но они на сегодня теряют смысл из-за высокой цены, сопоставимой с SSD дисками или даже дороже, и при этом уступают им в скорости и надёжности.
· 5400 об/м – самая низкая из возможных скорость вращения. Есть вариации чуть побыстрее, со скоростями в 5700-5940 об/м. Такие жёстки диски обладают наименьшей скоростью, но при этом слабее греются, малошумны и долговечны из-за пониженной нагрузки на механический узел. Стоит выбирать, если нужен максимальный объём и надёжность – хорошо подойдут в качестве «библиотечного» хранилища данных, или для хранения информации повышенной важности. Также подойдут в малогабаритные системы, где важно малое тепловыделение.
· 7200 об/м – стандартная скорость HDD, ей обладают большинство моделей. По скорости могут превосходить 5400 об/м в среднем в 1,5 раза. Если вы выбираете HDD в стандартный корпус пк, для вас не критичны небольшой шум и в корпусе организована нормальная система вентиляции то при выборе лучше ориентироваться именно на эту скорость. Перегрев HDD совсем не любят, диски 7200 об/м более чувствительны к режиму эксплуатации.
· IntelliPower – технология, которая предполагает выбор для каждого HDD индивидуальной скорости на этапе тестирования. В итоге скорость таких дисков колеблется около 5400 об/мин. Результат — уменьшено тепловыделение и шанс поломок, также в теории повышается долговечность.
Максимальная скорость передачи данных
Не всегда конечный параметр скорости передачи данных определяет скорость шпинделя – кроме этого есть ещё алгоритмы работы и внутренняя конструкция самого жёсткого диска. Например, на скорость может влиять количество магнитных дисков внутри – ёмкость в 1 ТБ может состоять как из 1-го диска, так и из 4-ёх по 250 ГБ.
Таким образом, по скорости можно выделить две группы HDD –со средними скоростями до 200 Мб/с, и более дорогая, но и самая скоростная среди магнитных жёстких дисков группа со скоростью более 200 Мб/с.
Дорогие модели HDD могут отличаться от дешёвых при равном объёме именно скоростью передачи данных, она будет заметно выше, благодаря многим факторам: может быть лучше оптимизирована кэш-память, иначе организован электро-механический узел, разное количество магнитных дисков на равный объём. Также зачастую дорогие диски более надёжны и устойчивы к внешним воздействиям.
Скорость передачи данных – совокупный результат всех остальных параметров и применённых в диске технологий, поэтому, если ваш выбор зависит в основном от скорости диска, то удобно ориентироваться именно по нему. Чем более диск скоростной, тем он будет дороже.
Ценовые категории
До 5000 рублей – можно позволить себе стандартный жёсткий магнитный диск ёмкостью до 2 ТБ, без кэша второго уровня. В этой группе лучше обратить внимание на модели ёмкостью в 500 ГБ – 1 ТБ. Они вряд ли будут отличаться высокими параметрами скорости, но это хороший и недорогой вариант, если вам нужен просто винчестер для рабочего компьютера.
От 5000 до 10000 рублей — в этой группе выбор будет зависеть от ваших основных требований – можно либо стремиться к максимальному объёмы накопителя, и приобрести 4 ТБ диск, либо обратить внимание на скорость работы, и тогда лучший выбор – гибридный диск SSHD объёмом до 2 ТБ. Также вы сможете себе позволить за эти деньги организовать RAID массив объёмом в 1-2 ТБ.
От 10000 до 20000 рублей – неплохим приобретением станет уже на 4 ТБ. Возможности растут пропорционально вложенным средствам – доступный объём увеличивается вплоть до 6-8 ТБ, при этом можно найти модель с повышенной скоростью передачи данных, от 200 Мб/с.
От 20000 рублей — возможности растут пропорционально вложенным средствам, и с таким бюджетом можно приобрести диски максимальным объёмом среди HDD – 10 ТБ, причём с большой скоростью и повышенной надёжностью. А также создать RAID массив огромной ёмкости. Единственный вариант, если жизненно важен именно максимальный объём хранилища. Приобретать стоит в профессиональных целях, вряд ли такое количество терабайт сможет заполнить рядовой пользователь.
Единицы измерения информации в компьютерах.
Говоря проще, скорость подключения это количество получаемой или отправляемой вашим компьютером информации в единицу времени.
Единицы измерения информации:
Бит (bit) – базовая единица измерения информации, может содержать только одну двоичную цифру. Бит может принимать только два значения: «0» или «1».
Байт (byte) – также единица количества информации, один байт равен восьми битам
Приставки К, М, Г, Т («кило-», «киби-» и т. д.)
Чтобы измерять большие объемы данных, используют кратные приставки. Привычная же нам приставка «кило-» означает умножение на 1000 (10х3 ), но в двоичной системе счисления используют два в десятой степени (2х10 ).
Двоичная система счисления
Для обозначения величины 2х10 =1024 байт, ввели двоичную приставку «К» (именно прописная буква «К»), но в разговорной речи единицу «К» стали называть «кило», что не совсем одно и то же. Чтобы не путаться ввели названия приставкам:
Т. е. второй слог изменили с привычного на «би», «бинарный».
Но от этого легче не стало, путаница не исчезла и многие расшифровывали «К» и «М» привычными «кило» и «мега».
Короче в итоге, чтобы окончательно убрать несоответствие, изменили не только названия,
Но как Вы понимаете от этого опять же легче не стало.
В народе говорят «кило», в программах ОС Windows пишут«К», в Linux обозначают «Ки»,
а производители жестких и оптических дисков пишут«К», а имеют в виду « Ки » и т. д.
В итоге на сегодняшний день имеются три варианта использования двоичных приставок.
Двоичные приставки в ОС Windows и производителей ОЗУ
1Кбайт (КБ или KB или Kbyte) = 1024байт
1Мбайт (МБ или MB или Mbyte) =1024Кбайт
1Гбайт (ГБ или MB или Gbyte) =1024Мбайт
1Тбайт (ТБ или TB или Tbyte) =1024Гбайт
В свойствах файлов почти все программы, да и сама операционная система Windows использует приставку в виде прописной буквы «К», «М», «Г» и т. д.
Производители оперативной памяти используют тот же принцип.
Двоичные приставки в ОС Windows и у производителей ОЗУ 1 Кбайт (КБ или KB или
Использование десятичных приставок
Если используется приставка «кило», «мега», «гига» и т. д., то имеются в виду следующие соотношения:
Десятичный приставки используют производители накопителей
1 килобайт (кБ или kB или kbyte) =1000 байт
1 мегабайт (МБ или MB или Mbyte)=1000килобайт=1 000 000байт
1гигабайт (ГБ или GB или Gbyte) =1000мегабайт=1 000 000Кбайт=1 000 000 000байт
1терабайт (ТБ или TB или Tbyte) =1000гигабайт=1 000 000Мегабайт=1 000 000 000Кбайт=1 000 000 000 000байт
Многих начинающих юзеров вводит в ступор после установки ОС, что диск обьемом 1000гб, отображается, как 931гб.
Как Windows видит два жестких диска 1ТБ и 500ГБ
Производители считают, что в нем 1 000 000 000 килобайт, а ОС Windows делит на 1024 и получает 976 562 500 Кбайт ( кибибайт) или 931 Гбайт (гибибайт ).
Жесткий диск 500 ГБ отображается как 465.76 ГБ, а винчестер объемом 1000 ГБ
содержит всего 931.51 гигабайт, т. е .70 гигов никуда не делись, просто гиг и байт на жестком диске меньше, чем гиг а байт.
1КБ=1 кибибайт= 1024байт
Теперь Вы знаете сколько байт в килобайте, а сколько в кибибайте
(бит в килобите и в кибибите)
Как правильно мерять производительность диска
abstract: разница между текущей производительностью и производительностью теоретической; latency и IOPS, понятие независимости дисковой нагрузки; подготовка тестирования; типовые параметры тестирования; практическое copypaste howto.
Предупреждение: много букв, долго читать.
Лирика
Это всё совершенно ошибочные методы. Дальше я разберу более тонкие ошибки измерения, но в отношении этих тестов могу сказать только одно — выкиньте и не используйте.
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’ы будут.
Драма состоит в том, что никто не знает, какие именно запросы придут. Маленькие? Большие? Подряд? В разнобой? Будут они прочитаны из кеша или придётся идти на самое медленное место и выковыривать байтики с разных половинок диска?
В результате мы получаем цифры, каждая из которых неправильная. Например: 15kIOPS и 150 IOPS.
Какая будет реальная производительность системы? Это определяется только тем, как близко будет нагрузка к хорошему и плохому концу. (Т.е. банальное «жизнь покажет»).
Ну и про размер блока. Традиционно тест идёт с размером блока в 4к. Почему? Потому что это стандартный размер блока, которым оперируют ОС при сохранении файла. Это размер страницы памяти и вообще, Очень Круглое Компьютерное Число.
Нужно понимать, что если система обрабатывает 100 IOPS с 4к блоком (worst), то она будет обрабатывать меньше при 8к блоке (не менее 50 IOPS, вероятнее всего, в районе 70-80). Ну и на 1Мб блоке мы увидим совсем другие цифры.
Всё? Нет, это было только вступление. Всё, что написано выше, более-менее общеизвестно. Нетривиальные вещи начинаются ниже.
Для удобства будем полагать, что время обработки нулевое. Если каждый запрос на чтение и запись будет обслуживаться 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/300×4 (т.е. 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 подразумевает использование т.н. 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
Задача подобрать такой iodepth, чтобы avg.latency была меньше 10мс.
Тесты на запись
(внимание! Ошибётесь буквой диска — останетесь без данных)
Гибридные тесты
самая вкусная часть:
(внимание! Ошибётесь буквой диска — останетесь без данных)
Анализ вывода
Во время теста мы видим что-то вроде такого:
В квадратных скобках — цифры IOPS’ов. Но радоваться рано — ведь нас интересует latency.
На выходе (по Ctrl-C, либо по окончании) мы получим примерно вот такое:
^C
fio: terminating on signal 2
Нас из этого интересует (в минимальном случае) следующее:
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 куда более подходящий вариант для теста.