Как правильно мерять производительность диска / Хабр

Основные физические и логические параметры жестких дисков

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

Диаметр дисков (disk diameter) – параметр довольно свободный от каких-либо стандартов, ограничиваемый лишь форм-факторами корпусов системных блоков. Наиболее распространены накопители с диаметром дисков 2.2, 2.3, 3.14 и 5.25 дюймов. Диаметр дисков определяет плотность записи на дюйм магнитного покрытия. Накопители большего диаметра содержат большее число дорожек, и в них, как правило, используются более простые технологии изготовления носителей, предназначенных для меньшей плотности записи. Они, как правило, медленнее своих меньших собратьев и имеют меньшее число дисков, но более надежны. Накопители с меньшим диаметром больших объемов имеют более высокотехнологичные поверхности и высокие плотности записи информации, а также, как правило, и большее число дисков.

Число поверхностей (sides number) – определяет количество физических дисков нанизанных на шпиндель. Выпускаются накопители с числом поверхностей от 1 до 8 и более. Однако, наиболее распространены устройства с числом поверхностей от 2 до 5. Принципиально, число поверхностей прямо определяет физический объем накопителя и скорость обработки операций на одном цилиндре. Так как операции на поверхностях цилиндра выполняются всеми головками синхронно, то теоретически, при равных всех остальных условиях, более быстрыми окажутся накопители с большим числом поверхностей.

Число цилиндров (cylinders number) – определяет, сколько дорожек (треков) будет располагаться на одной поверхности. В настоящее время все накопители емкостью более 1 Гигабайта имеют число цилиндров более 1024, вследствие чего, для распространенных ОС применяются унифицированные режимы доступа с пересчетом и эмуляцией и виртуализацией числа головок, цилиндров и секторов (LBA и Large).

Число секторов (sectors count) – общее число секторов на всех дорожках всех поверхностей накопителя. Определяет физический неформатированный объем устройства.

Число секторов на дорожке (sectors per track) – общее число секторов на одной дорожке. Часто, для современных накопителей показатель условный, т.к. они имеют неравное число секторов на внешних и внутренних дорожках, скрытое от системы и пользователя интерфейсом устройства.

Частота вращения шпинделя (rotational speed или spindle speed) – определяет, сколько времени будет затрачено на последовательное считывание одной дорожки или цилиндра. Частота вращения измеряется в оборотах в минуту (rpm). Для дисков емкостью до 1 гигабайта она обычно равна 5,400 оборотов в минуту, а у более вместительных достигает 7,200 и 10000 rpm.

Время перехода от одной дорожки к другой (track-to-track seek time) – обычно составляет от 3.5 до 5 миллисекунд, а у самых быстрых моделей может быть от 0.6 до 1 миллисекунды. Этот показатель является одним из определяющих быстродействие накопителя, т.к. именно переход с дорожки на дорожку является самым длительным процессом в серии процессов произвольного чтения/записи на дисковом устройстве. Показатель используется для условной оценки производительности при сравнении накопителей разных моделей и производителей.

Время успокоения головок (head latency time) – время, проходящее с момента окончания позиционирования головок на требуемую дорожку до момента начала операции чтения/записи. Является внутренним техническим показателем, входящим в показатель — время перехода с дорожки на дорожку.

Время установки или время поиска (seek time) – время, затрачиваемое устройством на перемещение головок чтения/записи к нужному цилиндру из произвольного положения.

Среднее время установки или поиска (average seek time) – усредненный результат большого числа операций позиционирования на разные цилиндры, часто называют средним временем позиционирования. Среднее время поиска имеет тенденцию уменьшаться с увеличением емкости накопителя, т.к. повышается плотность записи и увеличивается число поверхностей. Например, для 540-мегабайтных дисков наиболее типичны величины от 10 до 13, а для дисков свыше гигабайта — от 7 до 10 миллисекунд. Среднее время поиска является одним из важнейших показателей оценки производительности накопителей, используемых при их сравнении.

Время ожидания (latency) – время, необходимое для прохода нужного сектора к головке, усредненный показатель – среднее время ожидания (average latency), получаемое как среднее от многочисленных тестовых проходов. После успокоения головок на требуемом цилиндре контроллер ищет нужный сектор. При этом последовательно считываются адресные идентификаторы каждого проходящего под головкой сектора на дорожке. В идеальном, с точки зрения производительности случае, под головкой сразу окажется нужный сектор, в плохом — окажется, что этот сектор только что «прошел» под головкой, и, до окончания процесса успокоения необходимо будет ждать полный оборот диска для завершения операции чтения/записи. Это время у накопителей объемом от 540 мегабайт до 1 гигабайта составляет примерно 5.6, а у дисков свыше гигабайта — 4.2 миллисекунды и менее.

Время доступа (access time) – суммарное время, затрачиваемое на установку головок и ожидание сектора. Причем, наиболее долгим является промежуток времени установки головок.

Среднее время доступа к данным (average access time) – время, проходящее с момента получения запроса на операцию чтения/записи от контроллера до физического осуществления операции — результат сложения среднего время поиска и среднего времени ожидания. Среднее время доступа зависит от того, как организовано хранение данных и насколько быстро позиционируются головки чтения записи на требуемую дорожку. Среднее время доступа – усредненный показатель от многочисленных тестовых проходов, и обычно, оно составляет от 10 до 18 миллисекунд и используется как базовый показатель при сравнительной оценке скорости накопителей различных производителей.

Скорость передачи данных (data transfer rate), называемая также пропускной способностью (throughput), определяет скорость, с которой данные считываются или записываются на диск после того, как головки займут необходимое положение. Измеряется в мегабайтах в секунду (MBps) или мегабитах в секунду (Mbps) и является характеристикой контроллера и интерфейса. Различают две разновидности скорости передачи — внешняя и внутренняя. Скорость передачи данных, также является одним из основных показателей производительности накопителя и используется для ее оценки и сравнения накопителей различных моделей и производителей.

Внешняя скорость передачи данных (external data transfer rate или burst data transfer rate) показывает, с какой скоростью данные считываются из буфера, расположенного на накопителе в оперативную память компьютера. В настоящее время, накопители с интерфейсами EIDE или Fast ATA, обычно, имеют внешнюю скорость передачи данных от 11.1 до 16.6 мегабайта в секунду, а для накопителей с интерфейсами SCSI-2 — этот параметр находится в пределах от 10 до 40 мегабайт в секунду.

Внутренняя скорость передачи данных (internal transfer rate или sustained transfer rate) отражает скорость передачи данных между головками и контроллером накопителя и определяет общую скорость передачи данных в тех случаях, когда буфер не используется или не влияет (например, когда загружается большой графический или видеофайл). Внутренняя скорость передачи данных очень сильно зависит от частоты вращения шпинделя.

Размер кэш-буфера контроллера (internal cash size). Встроенный в накопитель буфер выполняет функцию упреждающего кэширования и призван сгладить громадную разницу в быстродействии между дисковой и оперативной памятью компьютера. Выпускаются накопители с 128, 256 и 512 килобайтным буфером. Чем больше объем буфера, тем потенциально выше производительность при произвольном «длинном» чтении/записи. Также, более емкий буфер обеспечивает рост производительности дисковой подсистемы, во-первых, при работе с объемными упорядоченными (записанными на диски последовательно) данными, а во-вторых — при одновременном обращении к диску множества приложений или пользователей, как это происходит в многозадачных сетевых ОС.

Средняя потребляемая мощность (capacity). При сборке мощных настольных компьютеров учитывается мощность, потребляемая всеми его устройствами. Современные накопители на ЖД потребляют от 5 до 15 Ватт, что является достаточно приемлемым, хотя, при всех остальных равных условиях, накопители с меньшей потребляемой мощностью выглядят более привлекательно. Это относится не только к экономии электроэнергии, но и надежности, т.к. более мощные накопители рассеивают избыток энергии в виде тепла и сильно нагреваются. А, как известно, проблемы, связанные с изменением свойств магнитных носителей напрямую зависят от их температуры и коэффициента расширения/сжатия материала.

Уровень шума (noise level), разумеется, является эргономическим показателем. Однако, он также, является и некоторым показателем сбалансированности механической конструкции, т.к. шум в виде треска — есть не что иное как звук ударов позиционера шагового или линейного механизма, а, даже микро- удары и вибрация так не желательны для накопителей и приводят к более быстрому их износу.

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

Сопротивляемость ударам (G-shock rating) – определяет степень сопротивляемости накопителя ударам и резким изменениям давления, измеряется в единицах допустимой перегрузки g во включенном и выключенном состоянии. Является важным показателем для настольных и мобильных систем.

Физический и логический объем накопителей. Носители жестких дисков, в отличие от гибких, имеют постоянное число дорожек и секторов, изменить которое невозможно. Эти числа определяются типом модели и производителем устройства. Поэтому, физический объем жестких дисков определен изначально и состоит из объема, занятого служебной информацией (разметка диска на дорожки и сектора) и объема, доступного пользовательским данным. Физический объем жесткого диска, также, зависит от типа интерфейса, метода кодирования данных, используемого физического формата и др. Производители накопителей указывают объемы дисков в миллионах байт, предполагая, исходя из десятичной системы исчисления, что в одном мегабайте 1000000 байт. Однако, ПО оперирует не десятичной, а двоичной системами, полагая, что в одном килобайте не 1000 байт, а 1024. Такие несложные разногласия в системах исчисления приводят к несоответствиям при оценке объема накопителей, данном в описании и — выдаваемом различными программными тестами.

Одним из возможных, но не желательных способов повышения физической емкости, для производителей, является увеличение емкости сектора. В настоящее время, стандартной емкостью сектора для IBM-совместимых компьютеров является 512 байт. Многие адаптеры позволяют, в процессе физического форматирования, программным путем, изменять емкость сектора, например, до 1024 байт. При этом соотношение пользовательских данных и служебной информации для сектора улучшается, но снижается надежность хранения данных, т.к. тот же полином ECC будет использоваться для коррекции большего объема данных. Однако, выигрыш на физическом уровне еще не означает тот же результат на логическом, т.к. логическая структура диска может оказаться не эффективной, например, при использовании для работы с файлами малой длинны (менее 1 К). Логический же объем зависит от того, как операционная система или программа записывает информацию в сектора. В случае использования программ и операционных систем с программной компрессией данных, можно повысить объем носителя на величину, зависящую от степени сжатия данных.

Для оптимального использования поверхности дисков применяется так называемая зонная запись (Zoned Bit Recording — ZBR), принцип которой состоит в том, что на внешних дорожках, имеющих большую длину (а, следовательно — и потенциальную информационную емкость на единицу площади), информация записывается с большей плотностью, чем на внутренних. Таких зон с постоянной плотностью записи в пределах всей поверхности образуется до десятка и более; соответственно, скорость чтения и записи на внешних зонах выше, чем на внутренних. Благодаря этому файлы, расположенные на дорожках с большим диаметром, в целом будут обрабатываться быстрее файлов, расположенных на дорожках с меньшим диаметром, т.к. для них будет производится меньшее число позиционирований с дорожки на дорожку.

В ЖД последнего поколения используются технологии PRML (Partial Response, Maximum Likelihood — максимальное правдоподобие при неполном отклике) и S.M.A.R.T. (Self Monitoring Analysis and Report Technology — технология самостоятельного слежения анализа и отчетности). Первая разработана по причине того, что при существующих плотностях записи уже невозможно четко и однозначно считывать сигнал с поверхности диска — уровень помех и искажений очень велик. Вместо прямого преобразования сигнала используется его сравнение с набором образцов, и на основании максимальной похожести (правдоподобия) делается заключение о приеме того или иного машинного слова.

Накопитель, в котором реализована технология S.M.A.R.T., ведет статистику своих рабочих параметров (количество стартов/остановок и наработанных часов, время разгона шпинделя, обнаруженные/исправленные физические ошибки и т.п.), которая регулярно сохраняется в перепрограммируемом ПЗУ или служебных зонах диска. Эта информация накапливается в течение всего периода эксплуатации и может быть в любой момент затребована программами анализа. По ней можно судить о состоянии механики, условиях эксплуатации или примерной вероятности выхода из строя.

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

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Мб блоке мы увидим совсем другие цифры.

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

• прочитать запись
• поменять запись
• записать запись обратно

Для удобства будем полагать, что время обработки нулевое. Если каждый запрос на чтение и запись будет обслуживаться 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 куда более подходящий вариант для теста.

Как узнать состояние и здоровье жесткого диска, как посмотреть показания SMART (HDD, SSD) и оценить сколько времени прослужит диск

И если в жизни предугадать некоторые события практически нереально, то вот в случае с жестким диском (да и твердотельным накопителем) — часть проблем всё же, предугадать и предвидеть можно!

Для этого существуют специальные утилиты, которые могут узнать и проанализировать показания SMART* диска (показать их вам, если необходимо), и на основе этих данных оценить состояние «здоровья» вашего диска, попутно рассчитав сколько лет он еще сможет прослужить.

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

И так, рассмотрю в статье несколько способов (и несколько утилит) анализа состояния HDD и SSD.

* Примечание:
S.M.A.R.T. (Self-Monitoring, Analysis and Reporting Technology) — специальная технология оценки состояния жёсткого диска системой интегрированной аппаратной самодиагностики/самонаблюдения. Основная задача — определить вероятность выхода устройства из строя, предотвратив потерю данных.

Оценка состояния жесткого диска: сколько лет он еще прослужит

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

Поэтому, в первой части статьи я решил показать пару утилит, которые могут получить все показания с диска и проанализировать их самостоятельно, а вам дать лишь готовый результат (во второй части статьи, приведу утилиты для просмотра показаний SMART для самостоятельного анализа).

Способ №1: с помощью Hard Disk Sentinel

Hard Disk Sentinel

Одна из лучших утилит для мониторинга состояния дисков компьютера (как жестких дисков (HDD), так и «новомодных» SSD). Что больше всего подкупает в программе — она все данные, полученные о состоянии диска, самостоятельно проанализирует и покажет Вам уже готовый результат (очень удобно для начинающих пользователей).

Чтобы не быть голословным, покажу сразу же главное окно программы, которое появляется после первого запуска (анализ диска будет сделан сразу автоматически 👇).

Здоровье и производительность диска оцениваются как 100% (в идеале, так и должно быть), время, которое диск еще проработает в нормальном режиме оценивается программой примерно в 1000 дней (~3 лет).

Что с диском по версии Hard Disk Sentinel

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

Также Hard Disk Sentinel позволяет просмотреть показания SMART (правда, чтобы оценить их, нужно неплохо разбираться в дисках), получить полную информацию о жестком диске (модель, серийной номер, производитель и пр.), посмотреть, чем жесткий диск загружен (т.е. получить сведения о производительности).

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

Hard Disk Sentinel работает во всех популярных Windows (7, 8, 10 — 32/64 bits), поддерживает русский язык в полном объеме.

Способ №2: с помощью HDDlife

HDDlife

Эта программа аналогична первой, также наглядно показывает текущее состояние диска: его здоровье и производительность (в процентном выражении), его температуру, количество отработанного времени (в месяцах). В верхней части окна, на основе всех этих данных, HDDlife показывает итоговое резюме по вашему диску, например, в моем случае «ALL RIGHT» (что значит, что с диском все в порядке).

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

Состояние HDD диска

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

С диском SSD не все в порядке.

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

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

Дополнение : HDDlife работает как на ПК, так и на ноутбуках. Поддерживает HDD и SSD диски. Есть в наличие портативные версии программы, не нуждающиеся в установке. Можно настроить так, чтобы программа запускалась вместе с вашей Windows. HDDlife работает в Windows: XP, 7, 8, 10 (32/64 bits).

Как посмотреть показания SMART

Если предыдущие утилиты самостоятельно оценивали состояние диска, на основе данных SMART, то нижеприведенные утилиты предоставят вам больше свободы и данных для самостоятельного анализа.

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

Способ №1: с помощью СrystalDiskInfo

СrystalDiskInfo

Отличная бесплатная утилита для просмотра состояния и показаний SMART жесткого диска (поддерживаются в том числе и SSD-диски). Чем подкупает утилита — она предоставляет вам полную информацию о температуре, техническому состоянию диска, его характеристиках и пр., причем, часть данных идут с пометками (т.е. утилита актуальна, как для опытных пользователей, которые сами знают «что-есть-что», так и для начинающих, которым нужна подсказка).

Например, если с температурой что-то не так — то вы увидите на ней красный индикатор, т.е. СrystalDiskInfo сам вам об этом сообщит.

Главное окно программы CrystalDiskInfo

Главное окно программы условно можно разбить на 4 зоны (см. скриншот выше):

1. «1» — здесь указаны все ваши физические диски, установленные в компьютере (ноутбуке). Рядом с каждым показана его температура, тех-состояние, и кол-во разделов на нем (например, «C: D: E: F:»);
2. «2» — здесь показана текущая температура диска и его тех-состояние (программа делает анализ на основе всех полученных данных с диска);
3. «3» — данные о диске: серийный номер, производитель, интерфейс, скорость вращения и пр.;
4. «4» — показания SMART. Кстати, чем подкупает программа — вам необязательно знать, что означает тот или иной параметр — если что-то не так с каким-либо пунктом, программа его пометит желтым или красным цветом и известит вас об этом.

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

В качестве справки (о переназначенных секторах):

когда жесткий диск обнаруживает, например, ошибку записи, он переносит данные в специально отведённую резервную область (а сектор этот будет считаться «переназначенным»). Поэтому на современных жёстких дисках нельзя увидеть bad-блоки — они спрятаны в переназначенных секторах. Этот процесс называют remapping, а переназначенный сектор — remap.

Чем больше значение переназначенных секторов — тем хуже состояние поверхности дисков. Поле «raw value» содержит общее количество переназначенных секторов.

Кстати, для многих производителей дисков, даже один переназначенный сектор — это уже гарантийный случай!

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

Чтобы утилита CrystalDiskInfo следила в режиме онлайн за состоянием вашего жесткого диска — в меню «Сервис» поставьте две галочки: » Запуск агента» и «Автозапуск» (см. скрин ниже).

Затем вы увидите значок программы с температурой рядом с часами в трее. В общем-то, за состояние диска теперь можно быть более спокойным. 😉

Способ №2: с помощью Victoria

Victoria — одна из самых знаменитых программ для работы с жесткими дисками. Основное предназначение программы оценить техническое состояние накопителя, и заменить поврежденные сектора на резервные рабочие.

Утилита бесплатна и позволяет работать как из-под Windows, так и из-под DOS (что во многих случаях показывает гораздо более точные данные о состоянии диска).

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

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

👉 В помощь!

Быстрая диагностика диска в Victoria: https://ocomp.info/diagnostika-i-proverka-diska.html

Источник https://studopedia.ru/10_109926_osnovnie-fizicheskie-i-logicheskie-parametri-zhestkih-diskov.html

Источник https://habr.com/ru/post/154235/

Источник https://ocomp.info/kak-uznat-sostoyanie-hdd-ssd.html