как узнать какой диск быстрее d или c

Как проверить скорость диска: HDD, SSD. Тест, определение разницы в скорости между SSD и HDD, стоит ли переходить на твердотельный диск?

Многие мастера рекомендуют купить SSD диск для более быстрой работы ПК (говорят даже компьютер будет включаться за 7-8 сек.). На самом деле скорость работы так вырастет? Смотрел сайты с дисками SSD, на них указана их скорость чтения и записи: к примеру, 535/545 МБ/с и интерфейс подключения SATA 6Gbit/s.

А как мне узнать текущую скорость моего HDD чтобы примерно прикинуть, на сколько вырастет скорость, и вообще, есть ли смысл от SSD? Заранее благодарю за ответ.

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

Если у вас тормозит диск, загружен на 100%, рекомендую ознакомиться вот с этой статьей.

Вопросы по скорости работы SSD, HDD

👉 Вопрос 1: какие утилиты и программы понадобятся для теста скорости HDD, SSD?

Ответ:

Пожалуй, это первое, с чего следует начать. Утилит таких много, выбор широкий. Лично я рекомендую выбрать пару утилит от одного производителя, речь идет о: CrystalDiskMark и CrystalDiskInfo. Именно в них и покажу, как, что и куда нажимать далее в статье.

CrystalDiskMark / CrystalDiskInfo

Утилиты можно скачать на одной страничке. Позволяют тестировать скорость работы диска, просматривать температуру диска, интерфейс подключения, показания SMART и многое другое. Поддерживают как HDD диски, так и новомодные твердотельные SSD. Работают во всех версиях Windows: XP, Vista, 7, 8, 8.1, 10 (32/64 bits).

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

👉 Вопрос 2: как проверить скорость работы диска в CrystalDiskMark?

Ответ:

Скачивание и установку утилиты пропускаю. Далее необходимо:

Результаты тестирования HDD

Выводы:

👉 Вопрос 3: как определить режим работы SATA жесткого диска? Интерфейс подключения.

Ответ:

Что касается режима работы SATA — то просто посмотрите на строку «Режим передачи». Расшифрую пару моментов:

👉 Вопрос 4: какая разница в скорости между SSD и HDD?

Ответ:

Смотря на каком компьютере. Если у вас старый ПК, не поддерживающий SATA 3.0 — то получить максимальную производительность от SSD диска вы не сможете.

Вообще, в среднем, показатель последовательной скорости чтения/записи у SSD диска в 5 раз выше, чем у HDD (см. скриншот ниже, про другие уж показатели, можно промолчать 😉). Думаю, этого скриншота достаточно, чтобы приближенно оценить: например, если у вас раньше ПК загружался за 60 сек. — то после установки SSD: станет ориентировочно за 12-15 сек.

👉 Вопрос 5: правда ли что SSD диски долго не «живут»?

Ответ:

В остальном же, это не так. Вот, например, на скриншоте ниже показаны официальные данные от производителя SSD дисков Kingston. Для диска в 240 ГБ — можно записать порядка 80 ТБ (что около 80000 ГБ!).

Число записываемых байтов, диски SSD Kingston серия A-400

В свою очередь, путем не сложных расчетов, можно получить, что при записи 20 ГБ в день (например, пару игр, фильмов) — диск прослужит порядка 10 лет!

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

👉 Вопрос 6: время загрузки Windows станет 8 сек., правда?

Ответ:

И да, и нет. Дело в том, что сложно сказать о том, за сколько загрузится ваша ОС Windows, т.к. на это влияет много факторов: какая реальная будет скорость работы нового SSD диска, сколько и какие программы у вас в автозагрузке, версия Windows, оптимизирована ли она и т.д.

👉 Кстати, насчет оптимизации Windows, рекомендую ознакомиться вот с этой инструкцией.

Вот один из примеров на фото ниже: после установки SSD система (Windows 7) стала загружаться за 15 сек., вместо 49. По-моему, весьма неплохое ускорение.

Загрузка Windows разница

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

👉 Вопрос 7: стоит ли переходить на SSD диск? Его основные преимущества.

Ответ:

Пожалуй, здесь решает каждый сам для себя. Мое мнение, если есть средства — то, конечно, стоит (по крайней мере, под системный диск с Windows). Приведу основные преимущества, и прокомментирую их, а уж там сами решите.

👉 Вопрос 8: сейчас стали появляться SSD M2 диски (которые в несколько раз быстрее чем SATA диски). Стоит ли на них переходить?

Ответ:

Во-первых, диски SSD M2 могут быть разными: как SATA, так и PCI-E (SATA вариант работает точно с такой же скоростью как классические SSD).

Если говорить о современных SSD M2 (NVMe) — то да, в синтетических тестах они показывают раз в 5 большую производительность, чем SSD (SATA III). Скрин теста привел ниже. 👇

SSD M2: как выбрать накопитель (тонкости с SATA и PCI-E, 2242, 2260, 2280, и ключами).

Однако, на практике (в реальных задачах) — разница в скорости не так уж очевидна. Например, различные документы Word, Excel и пр. «мелочь» будут открываться на SSD (NVMe) также моментально, как и на SSD SATA.

При загрузке Windows — можно выиграть 3-5 сек., некоторые уровни игр будут загружаться быстрее (например, WOW на скрине ниже: 15 сек. против 13 сек.; но это не так существенно (на мой взгляд) ).

Скорость загрузки игры — 15 сек. против 13 сек. (SSD M2 NVMe и SSD SATA)

В общем, если подводить некий итог:

👉 Ниже привел небольшое видео, на котором четко показано насколько быстро ведет себя один и тот же компьютер, к которому подключены разные накопители SSD vs HDD (разница 2,5 раза!).

Источник

Как делается проверка скорости жёсткого диска

Производительность компьютера является комплексной величиной и зависит от характеристик всех компонентов в сборке. Один из факторов, напрямую влияющих на скорость выполнения операций — показатель скорости работы HDD. Его часто оставляют без внимания, хотя накопитель может ограничивать быстродействие компьютера, что выражается в низкой скорости обработки данных, копирования файлов, медленной загрузке операционной системы, игр и прочего софта.

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

От чего зависит скорость жёсткого диска

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

Вращение шпинделя

Функционирование жёсткого диска осуществляется за счёт движущихся механизмов, применённых в конструкции винчестера. Запись данных на носитель выполняется путём намагничивания магнитной головкой участков ферромагнитного покрытия, нанесённого на поверхность жёстких пластин. В процессе работы при необходимости считывания/ записи информации головка, приводимая в движение электроприводом, быстро движется над поверхностью вращающихся дисков. Так что, главное, от чего зависит скорость накопителя HDD, — скорость вращения частей устройства (об/мин).

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

Сегодня стандартным значением для скоростных показателей шпинделя HDD считается 7200 оборотов в минуту. Модели жёстких дисков с большим показателем целесообразно использовать в серверных установках, а не дома. Следует учитывать, что кроме увеличения скорости и уменьшения задержки при перемещении головки (этот показатель измеряется в миллисекундах и в среднем оптимальным будет 7-14 мс) растёт и шум при работе устройства, а также тепловыделение и энергопотребление.

Ёмкость диска

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

На скоростные характеристики влияет и объём кэша, сохраняющий сведения при первом обращении к определённым данным для быстрого доступа в дальнейшем. Так, чем больше буфер, тем больше в него поместится, а значит, повторное считывание той же информации будет происходить в разы быстрее. Сегодня можно найти модели с 128 или 256 МБ кэш-памяти.

Поддержка технологий

Не последнее значение имеет и поддержка стандартов жёстким диском. Например, технология NCQ, используемая в SATA-устройствах начиная с SATA/300 (Native Command Queuing — аппаратная установка очерёдности команд), позволяет накопителю принимать одновременно несколько запросов, перестраивая порядок их выполнения для наибольшей эффективности с учётом конструктивного исполнения устройства, что и способствует высокой скорости чтения. Устаревшая технология TCQ (тегированная очередь команд), используемая в некоторых ATA и SCSI жёстких дисках, похвастать высокой эффективностью по части повышения производительности не может ввиду некоторых ограничений по количеству посылаемых одновременно команд.

Другие факторы

Ещё один момент — скорость порта подключения диска к плате. SATA первого поколения обеспечивает пропускную способность до 1,5 Гбит/с, тогда как интерфейс SATA 2 уже может предложить до 3 Гбит/с, а спецификация SATA 3 — до 6 Гбит/С. Причём, хотя совместимость разъёмов и протоколов обмена и сохранена, на быстродействии может отразиться использование современного накопителя на старой материнке ввиду ограничений, так как использоваться будут возможности интерфейса предыдущего поколения. Чтобы выжать максимальное быстродействие, оба устройства должны поддерживать стандарт.

Отличаться производительность может на дисках, использующих разные файловые системы. Например, в случае с популярными системами FAT 32 и NTFS при прочих равных первая обеспечит накопителю более высокую скорость чтения, поскольку вторая более подвержена фрагментации системных участков, в результате чего совершается больше движений.

Нормы скорости

Чтобы взаимодействие с компьютером было комфортным, HDD должен работать на достаточной скорости, но учитывать нужно и характер выполняемых операций. Быстродействие отличается и при работе с файлами разного объёма.

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

Скорость средних HDD — 150-200 МБ/с, чего более чем достаточно для повседневных задач. Те винчестеры, чьи показатели превышают 200 МБ/с отличаются также и высокой стоимостью, поэтому чаще всего целесообразнее приобрести SSD, если есть необходимость в высокоскоростном накопителе. Файлы объёмом свыше 500 МБ должны читаться HDD со скоростью от 150 МБ/с, тогда как нормальной для системных файлов, обычно занимающих не более 8 Кб, будет 1 МБ/с.

Сторонние программы

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

Проверка скорости жёсткого накопителя HDD в операционной системе Windows 7 или «Десятке» может выполняться с использованием стороннего софта или встроенного в систему инструмента. Результат будет получен после проведения тестирования винчестера. Для начала рассмотрим первый вариант и разберёмся, как узнать скорость HDD на примере нескольких популярных программ.

CrystalDiskMark

Одна из лучших утилит для работы с разными типами накопителей — HDD и SSD в ОС Windows 10, 8, 7 и других популярных системах, отличающаяся удобством и простотой интерфейса (поддерживается русский). Чтобы с её помощью проверить скорость чтения и записи жёсткого диска, нужно выполнить следующие действия:

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

HD Tune

Ещё одна отличная программа, выполняющая тест скорости жёсткого диска в Windows 10, 8, 7. Есть бесплатная версия программы и платная с 15-дневным демонстрационным периодом. Чтобы узнать, какая у тестируемого винчестера скорость чтения/записи, выполняем:

По завершении утилита выдаст результаты тестов в цифрах и графиках, благодаря которым можно узнать минимальную, максимальную, среднюю, пиковую скорость, а также загрузку ЦП при тестировании.

Ashampoo HDD Control

Отличная утилита с понятным интерфейсом и достойным функционалом для контроля состояния жёсткого диска, поддерживающая разные типы накопителей. Программа платная с возможностью 40-дневного бесплатного использования, поддерживается русский интерфейс. С её помощью можно проанализировать, в том числе скорость передачи данных — бенчмарк даёт развёрнутую информацию. Чтобы провести тестирование, выполняем следующее:

По завершении процесса будет доступна подробная информация о скорости работы диска и задержках.

Командная строка PowerShell

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

Атрибуты применяются только по отдельности.

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

Источник

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

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 куда более подходящий вариант для теста.

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

Источник