Проверить скорость диска на сервере
На этом диске будут проводится тесты, описанные ниже:
Western Digital Caviar Green 500GB 64МB WD5000AZRX 3.5
О том, как получить подробные данные о вашем жестком диске – можно прочитать в статье Linux: получение информации о hardware — HDD.
О параметрах S.M.A.R.T.
Сама аббревиатура S.M.A.R.T. литературно расшифровывается как система контроля и самодиагностики диска. Она выполняется контроллером памяти, который нередко указывается в спецификациях SSD–диска. Одна из задач контроллера в распределении нагрузки на ячейки памяти, для равномерного заполнения ресурса по операциям записи. А вообще причина в том, что жесткие диски и твердотельные накопители смертны.
Причем “смертны неожиданно”, если цитировать Воланда. Но так было раньше, до появления стандартизированных инструментов самодиагностики S.M.A.R.T., без которых трудно представить современную диагностику и прогнозирование износа оборудования. В пакет собираемой информации входят ошибки по чтению и записи на каждый блок, и еще около полусотни параметров, названных атрибутами.
Именно атрибуты S.M.A.R.T. позволяют утилите CrystalDiskInfo выводить остаток ресурса, температуру, общее число записанных на диск данных, а также суммарную наработку по часам. Для Ubuntu этот софт не выпускается, но владельцам компьютеров под управлением данной системы он и не требуется.
hdparm
Начнём с программы hdparm :
Ключ -t ( Timing buffered disk) отображает скорость чтения с диска напрямую из буфера кеша, и является показателем того, как быстро жесткий диск может поддерживать последовательное чтение данных под Linux, без задержек, вызванных работой файловой системы.
Ключ -T (Timing cached reads) показывает скорость чтения напрямую из буфера кеша Linux без учёта доступа к диску. Этот показатель главным образом отображает работу процессора, кэша и оперативной памяти тестируемой системы.
Проверка скорости записи на диск
Для того, чтобы измерить скорость записи на диск, можно воспользоваться стандартной утилитой linux - dd. С ее помощью мы создадим на диске файл размером 1 Gb частями по 1Mb.
Измеряем скорость записи на диск:
Я измерял скорость на виртуальной машине, диск которой был размещен на RAID5, собранным из 5-ти дисков SAS 10к. В принципе, неплохой результат. Можно изменить размер файла и блоков, из которого он записывается. Если сделать файл побольше, результат скорости диска может получиться более приближенный к реальности.
А вот скорость диска на VDS, который я арендую. Результат в разы хуже:
Скорость диска на виртуальной машине, расположенной на втором SATA диске моего рабочего ноутбука:
Результат не очень, надо разбираться в чем дело. Давно возникли подозрения, что с диском что-то не то, заметно подтормаживают виртуальные машины, хотя раньше это было не заметно. Жаль, результатов более ранних тестов не сохранилось.
Интересно было бы посмотреть на ваши результаты тестов. Если же вы хотите серьезно измерить скорость дисков, то вам сюда - Как правильно мерять производительность диска.
Если у вас есть желание научиться строить и поддерживать высокодоступные и надежные системы, научиться непрерывной поставке ПО, мониторингу и логированию web приложений, рекомендую познакомиться с онлайн-курсом «DevOps практики и инструменты» в OTUS. Курс не для новичков, для поступления нужны базовые знания по сетям и установке Linux на виртуалку. Обучение длится 5 месяцев, после чего успешные выпускники курса смогут пройти собеседования у партнеров.
Проверьте себя на вступительном тесте и смотрите подробнее программу ссылке.
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.
Какая будет реальная производительность системы? Это определяется только тем, как близко будет нагрузка к хорошему и плохому концу. (Т.е. банальное «жизнь покажет»).
- Что best case всё-таки best. Потому что можно дооптимизироваться до такого, что best case от worst будет отличаться едва-едва. Это плохо (ну или у нас такой офигенный worst).
- На 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. Диск работает на пределе возможностей, но входящих обращений больше, чем скорость их обслуживания. Latency начинает стремительно расти, достигая ужасающих цифр в единицы секунд (и это при том, что приложению, например, для завершения работы нужно сделать 100 операций, которые при latency в 5 мс означали полусекундную задержку. ). Это состояние называется thrashing.
Вы будете удивлены, но любой диск или хранилище способны показывать БОЛЬШЕ IOPS'ов в состоянии thrashing, чем в нормальной загрузке. Причина проста: если в нормальном режиме очередь чаще всего пустая и кассир скучает, ожидая клиентов, то в условии трешинга идёт постоянное обслуживание. (Кстати, вот вам и объяснение, почему в супермаркетах любят устраивать очереди — в этом случае производительность кассиров максимальная). Правда, это сильно не нравится клиентам. И в хороших супермаркетах хранилищах такого режима стараются избегать. Если дальше начинать поднимать глубину очереди, то производительность начнёт падать из-за того, что переполняется очередь и запросы стоят в очереди чтобы встать в очередь (да-да, и порядковый номер шариковой ручкой на на руке).
И тут нас ждёт следующая частая (и очень трудно опровергаемая) ошибка тех, кто меряет производительность диска.
Они говорят «у меня диск выдаёт 180 IOPS, так что если взять 10 дисков, то это будет аж 1800 IOPS». (Именно так думают плохие супермаркеты, сажая меньше кассиров, чем нужно). При этом latency оказывается запредельной — и «так жить нельзя».
Реальный тест производительности требует контроля latency, то есть подбора таких параметров тестирования, чтобы latency оставалась ниже оговоренного лимита.
И вот тут вот мы сталкиваемся со второй проблемой: а какого лимита? Ответить на этот вопрос теория не может — этот показатель является показателем качества обслуживания. Другими словами, каждый выбирает для себя сам.
Лично я для себя провожу тесты так, чтобы latency оставалась не более 10мс. Этот показатель я для себя считаю потолком производительности хранилища. (при этом в уме я для себя считаю, что предельный показатель, после которого начинают ощущаться лаги — это 20мс, но помните, про пример выше с 900 по 1мс и 10 по 100мс, у которого avg стала 10мс? Вот для этого я и резервирую себе +10мс на случайные всплески).
Выше мы уже рассмотрели вопрос с зависимыми и независимыми IOPS'ами. Производительность зависимых Iops'ов точно контролируется latency, и этот вопрос мы уже обсудили. А вот производительность в независимых iops'ах (т.е. при параллельной нагрузке), от чего она зависит?
Отдельно нужно говорить про ситуацию, когда хранилище подключено к хосту через сеть с использованием TCP. О TCP нужно писать, писать, писать и ещё раз писать. Достаточно сказать, что в линуксе существует 12 разных алгоритмов контроля заторов в сети (congestion), которые предназначены для разных ситуаций. И есть около 20 параметров ядра, каждый из которых может радикальным образом повлиять на попугаи на выходе (пардон, результаты теста).
С точки зрения оценки производительности мы должны просто принять такое правило: для сетевых хранилищ тест должен осуществляться с нескольких хостов (серверов) параллельно. Тесты с одного сервера не будут тестом хранилища, а будут интегрированным тестом сети, хранилища и правильности настройки самого сервера.
Последний вопрос — это вопрос затенения шины. О чём речь? Если у нас ssd способна выдать 400 МБ/с, а мы её подключаем по SATA/300, то очевидно, что мы не увидим всю производительность. Причём с точки зрения latency проблема начнёт проявляться задолго до приближения к 300МБ/с, ведь каждому запросу (и ответу на него) придётся ждать своей очереди, чтобы проскочить через бутылочное горлышко SATA-кабеля.
Но бывают ситуации более забавные. Например, если у вас есть полка дисков, подключенных по SAS/300x4 (т.е. 4 линии SAS по 300МБ каждая). Вроде бы много. А если в полке 24 диска? 24*100=2400 МБ/с, а у нас есть всего 1200 (300х4).
Более того, тесты на некоторых (серверных!) материнских платах показали, что встроенные SATA-контроллеры часто бывают подключены через PCIx4, что не даёт максимально возможной скорости всех 6 SATA-разъёмов.
Повторю, главной проблемой в bus saturation является не выедание «под потолок» полосы, а увеличение latency по мере загрузки шины.
Ну и перед практическими советами, скажу про известные трюки, которые можно встретить в индустриальных хранилищах. Во-первых, если вы будете читать пустой диск, вы будете читать его из «ниоткуда». Системы достаточно умны, чтобы кормить вас нулями из тех областей диска, куда вы никогда не писали.
Во-вторых, во многих системах первая запись хуже последующих из-за всяких механизмов снапшотов, thin provision'а, дедупликации, компрессии, late allocation, sparse placement и т.д. Другими словами, тестировать следует после первичной записи.
В третьих — кеш. Если мы тестируем worst case, то нам нужно знать, как будет вести себя система когда кеш не помогает. Для этого нужно брать такой размер теста, чтобы мы гарантированно читали/писали «мимо кеша», то есть выбивались за объёмы кеша.
Кеш на запись — особая история. Он может копить все запросы на запись (последовательные и случайные) и писать их в комфортном режиме. Единственным методом worst case является «трешинг кеша», то есть посыл запросов на запись в таком объёме и так долго, чтобы write cache перестал стправляться и был вынужден писать данные не в комфортном режиме (объединяя смежные области), а скидывать случайные данные, осуществляя random writing. Добиться этого можно только с помощью многократного превышения области теста над размером кеша.
Вердикт — минимум x10 кеш (откровенно, число взято с потолка, механизма точного расчёта у меня нет).
Разумеется, тест должен быть без участия локального кеша ОС, то есть нам надо запускать тест в режиме, который бы не использовал кеширование. В линуксе это опция O_DIRECT при открытии файла (или диска).
Итого:
1) Мы тестируем worst case — 100% размера диска, который в несколько раз больше предположительного размера кеша на хранилище. Для десктопа это всего лишь «весь диск», для индустриальных хранилищ — LUN или диск виртуальной машины размером от 1Тб и больше. (Хехе, если вы думаете, что 64Гб RAM-кеша это много. ).
2) Мы ведём тест блоком в 4кб размером.
3) Мы подбираем такую глубину параллельности операций, чтобы latency оставалось в разумных пределах.
На выходе нас интересуют параметры: число IOPS, latency, глубина очереди. Если тест запускался на нескольких хостах, то показатели суммируются (iops и глубина очереди), а для latency берётся либо avg, либо max от показателей по всем хостам.
Тут мы переходим к практической части. Есть утилита fio которая позволяет добиться нужного нам результата.
Нормальный режим fio подразумевает использование т.н. job-файла, т.е. конфига, который описывает как именно выглядит тест. Примеры job-файлов приведены ниже, а пока что обсудим принцип работы fio.
fio выполняет операции над указанным файлом/файлами. Вместо файла может быть указано устройство, т.е. мы можем исключить файловую систему из рассмотрения. Существует несколько режимов тестирования. Нас интересует randwrite, randread и randrw. К сожалению, randrw даёт нам зависимые iops'ы (чтение идёт после записи), так что для получения полностью независимого теста нам придётся делать две параллельные задачи — одна на чтение, вторая на запись (randread, randwrite).
И нам придётся сказать fio делать «preallocation». (см выше про трюки производителей). Дальше мы фиксируем размер блока (4к).
Ещё один параметр — метод доступа к диску. Наиболее быстрым является libaio, именно его мы и будем использовать.
При тесте диска запускать её надо от root'а.
tune2fs
Более подробную информацию об используемой файловой системе посмотреть можно с помощью tune2fs :
Filesystem features: has_journal ext_attr resize_inode dir_index filetype needs_recovery extent flex_bg sparse_super large_file huge_file uninit_bg dir_nlink extra_isize
Конечно же, перед выполнением тестов убедитесь, что не запущены никакие задачи, создающие нагрузку на дисковую систему.
Самый простой способ проверки скорости чтения/записи на жесткий диск ( hard disk input/output value ):
Лучше выполнять его хотя бы 1-2 минуты. Почему – пояснение в следующих примерах:
424 МБ/с – по сравнению с 113 MB/s в предыдущем примере – почему такая разница?
dd вывел результат кеширования в буфер оперативной памяти, а не непосредственно на диск.
Укажем выполнить не 100 операций, а 1000 – что бы система успела выполнить синхронизацию RAM и HDD, после чего dd покажет нам результаты:
113 MB/s – тоже более реальный результат для это жесткого диска.
Другой способ – прямо указать dd дождаться окончания синхронизации данных (т.е. после фактического завершения операций записи/чтения данных на диск):
Теперь рассмотрим некоторые утилиты.
iozone
Следующая утилита – iozone , которая фактически умеет выполнять все тесты, описанные выше. В Ubuntu 12.04 она требует установки, поэтому выполняем:
Теперь запустим и рассмотрим результаты:
64 4 474430 818885 2561267 2561267 1879725 1124074 1124074 1188789 2116903 799377 939223 1105556 2133730
64 8 167061 852702 1452528 3057153 2133730 1210227 955947 2052169 1330167 1101022 901377 533875 1828508
64 16 560635 614542 2298136 2561267 5389653 1255511 1562436 1279447 1933893 913649 460591 1879725 2444640
64 32 566551 1033216 3363612 3203069 6421025 1526887 1421755 1452528 1947927 1124074 1304314 1452528 2298136
64 64 507625 1066042 5389653 5389653 5389653 1304314 1492919 1484662 1421755 1002351 1183548 1991276 2006158
(тут показана лишь малая часть всего вывода)
Ключ -a запускает iozone в автоматическом режиме, в котором утилита будет использовать для тестирования block size от 4k до 16384k (16M), и размер файлов от 64k до 524288k (512M).
Все результаты скорости указаны в KB/Sec.
Первая колонка – KB отображает размер файла.
Вторая колонка – reclen – отображает используемый размер блока (block size).
Третья колнка – write – отображает время, затраченное на создание/запись нового файла. Это всегда более сложная задача для диска и файловой системы, так как связана с назначением inode , созданием новой записи в журнале событий (для Journaled File System ) и т.п.
Четвёртая колонка – rewrite – указывается скорость перезаписи уже существующего файла.
Пятая колонка – read – скорость чтения существующего файла.
Шестая колонка – reread – скорость чтения файла, который уже был прочитан ( reread file ).
Седьмая колонка – random read – показывает скорость доступа к случайной части (!) файла.
В целом, этих данных хватит для получения необходимых данных о быстродействии жесткого диска. Более подробные данные можно еполучить на сайте>>> разработчкиа.
Сохранить результаты можно с ключём -b (файл должен быть совсемстим с форматом эл. таблиц):
Есть ещё много утилит, однако на этом хочется закончить.
Основная часть этой статьи является вольным переводом (с некоторыми попавками в описаниях) статьи Linux File System Read Write Performance Test.
Иногда хочется быстро прикинуть, как работает дисковая подсистема, либо сравнить 2 жестких диска. Очевидно, что измерить реальную скорость дисков практически невозможно, она зависит от слишком большого числа параметров. Но получить некое представление о скорости дисков можно.
Если у вас есть желание научиться строить и поддерживать высокодоступные и надежные системы, рекомендую познакомиться с онлайн-курсом «DevOps практики и инструменты» в OTUS. Курс не для новичков, для поступления нужно пройти вступительный теcт.
tune2fs
Более подробную информацию об используемой файловой системе посмотреть можно с помощью tune2fs :
Filesystem features: has_journal ext_attr resize_inode dir_index filetype needs_recovery extent flex_bg sparse_super large_file huge_file uninit_bg dir_nlink extra_isize
Конечно же, перед выполнением тестов убедитесь, что не запущены никакие задачи, создающие нагрузку на дисковую систему.
Самый простой способ проверки скорости чтения/записи на жесткий диск ( hard disk input/output value ):
Лучше выполнять его хотя бы 1-2 минуты. Почему – пояснение в следующих примерах:
424 МБ/с – по сравнению с 113 MB/s в предыдущем примере – почему такая разница?
dd вывел результат кеширования в буфер оперативной памяти, а не непосредственно на диск.
Укажем выполнить не 100 операций, а 1000 – что бы система успела выполнить синхронизацию RAM и HDD, после чего dd покажет нам результаты:
113 MB/s – тоже более реальный результат для это жесткого диска.
Другой способ – прямо указать dd дождаться окончания синхронизации данных (т.е. после фактического завершения операций записи/чтения данных на диск):
Теперь рассмотрим некоторые утилиты.
Тесты на запись
(внимание! Ошибётесь буквой диска — останетесь без данных)
Бенчмарк и просмотр S.M.A.R.T. на Ubuntu
Классическая проверка жестких дисков и просмотр параметров S.M.A.R.T. в Ubuntu выполняются через терминал, с использованием Smartmontools. Ровно тем же инструментарием SmartCtl можно проверить данные с диска, не вводя команды в терминале. Для этого достаточно установить графическое приложение GSmartControl, находящееся в свободном доступе на популярных репозиториях.
Зато при подключении SSD-диска 3-х летней давности, в меню приложения GSmartControl вся информация из S.M.A.R.T. доступна буквально парой кликов. Тут и актуальная температура, и счетчик исполнений циклов, и общее время работы. Подробнее о значениях каждого из параметров можно прочитать в постах у хабровчан, вбив аббревиатуру в поиск.
Сразу вопрос: а почему свежий NVMe–накопитель Kingston A2000 не распознается приложением GSmartControl? И главное, почему установленный через терминал Smartmontools выдает ту же ошибку доступа к данным самодиагностики?
тесты на чтение
Запуск: fio read.ini
Содержимое read.ini
Задача подобрать такой iodepth, чтобы avg.latency была меньше 10мс.
seeker
Одним из очень важных параметров скорости работы жесткого диска является “seek time” – время поиска. Это время, которое требуется жестком диску, что бы считывающая головка достигла сектора, содержащего необходимые данные. Что бы проверить этот параметр – воспользуемся утилитой seeker :
К сожалению, что бы её запустить под Debian / Ubuntu придётся немного повозиться.
Для начала, качаем .rpm пакет с сайта:
Например, вполне работоспособным (на Ubuntu 12.04 x64) оказался пакет seeker-3.0-2.el6.x86_64.rpm для CentOS 5.
Download packages from the official mirror:
binary package, source package
binary – и сохраняем пакет .rpm на диск.
Далее, потребуется создать пакет .deb . Для этого можно воспользоваться утилитой alien . Как ей пользоваться – описано в статье Установка Java 7 на Ubuntu 12.10.
Самое интересное в результате – это значение “89 seeks/second” , т.е. 89 попыток поиска в секторе, содержащем данные. Это неплохой результат для домашнего ПК, но неважный для серверной машины. Впрочем, учитывая что на этой машине используется “домашний” винчестер WD серии Green с RPM 5200 – то вполне неплохой результат.
Проблема в Ubuntu или диске?
В нашем случае, для Ubuntu актуальная версия Smartmontools датирована версией 7.1 из конца 2019 года. Под Windows и Linux, типа Fedora, доступна версия 7.2 от конца октября 2020 года. Но причина оказалась даже не в этом, а в отсутствии информации об SSD–диске Kingston A2000 в самой свежей версии базы драйверов под Linux-системы.
Для проверки, та же операция по обновлению базы была проведена на свежем дистрибутиве Fedora 33. В таблице релизов Smartmontools для этой системы заявлена актуальная версия приложения 7.2. А ручное обновление базы дисков, используемое GsmartTools, также выполняется через терминал, вводом команды: sudo/usr/sbin/update-smart-drivedb
Результат ожидаемо не привел к положительному результату. С одной стороны, разработчиков можно понять, но пользоваться хочется современным SSD–накопителем, не привязывая себя к определенной операционной системе. А в случае с Linux остается только попробовать другую актуальную модель из доступной линейки дисков: модель Kingston A400. Этот SATA-SSD выполнен в форм-факторе 2.5”, так что есть шанс узнать еще и данные по температуре у подобного твердотельника.
Получится у Linux прочитать S.M.A.R.T.–параметры диска Kingston A400?
Момент установки был волнителен как никогда. Прежде чем было принято решение брать другой диск для проверки, были испробованы различные команды в терминале и бесчисленные попытки обновления софта. Порой казалось, что вот сейчас все получится, но результата не удавалось достичь. Надежды на успех были минимальны.
Ура, победа! Твердотельный накопитель Kingston A400 распознается без каких-либо ограничений и все данные самодиагностики S.M.A.R.T. доступны в полном объеме. Значения ошибок и температура доступна к просмотру, причем и в классическом приложении Диски. Там же можно запустить бенчмарк чтения и записи, с ручным выставлением параметров объема ячейки и количества операций. В сочетании с GsmartControl получается удобное средство для контроля производительности дисковой подсистемы, в частности температурного.
В случае с твердотельным накопителем Kingston A400 емкостью 480 ГБ, пиковые значения температуры, по данным приложения GSmatControl, не превышали 60 °С. Результат действительно интересный. Согласно ему, выходит, что системный Kingston A400 выглядит предпочтительнее для Linux, как раз благодаря низкому тепловыделению. NVMe–накопитель грелся в Windows до 70-ти градусов и лучше использовать его с операционкой Microsoft.
Что интересно, за пару месяцев подготовки этого материала, не только разрушились надежды обнаружить с обновлением драйвера и поддержку Kingston A2000 в Linux, но и потерял свою актуальность дистрибутив из репозиториев Fedora для утилиты KDiskMark. Еще в феврале-марте никаких проблем с его установкой из штатного магазина не возникало, а теперь увы.
А жаль, ведь результаты записи в этом бенчмарке гораздо адекватнее значений, выводимых штатными “Дисками”, независимо от введенных значений. Запись упорно держится в районе 300 МБ/с, хотя визуально предпосылок к обрезанной скорости нет.
Какие итоги мы смогли вынести из увиденного?
Первый и самый очевидный вывод, по итогам поиска утилит мониторинга твердотельных дисков на Linux, оказался довольно очевиден: для новинок железа и подробного тестирования куда лучше подходит Windows. Операционка от Microsoft хорошо заточена под обновление драйверов отдельных компонентов, на нее ориентируются производители игрового железа и даже среди дисковых утилит там есть, из чего выбрать.
С Linux-системами все несколько сложнее. Там меньше конкуренция и ниже фокус внимания разработчиков софта. В нашей конкретной ситуации два SSD-накопителя, выпущенные в схожее время, проявили себя по-разному. Модель A400 распознается системами Ubuntu и Fedora, в утилитах Диски и GSmartControl доступен полный отчет по S.M.A.R.T. – параметрам, а вот модель A2000 так и не получила системных драйверов на апрель 2021 года. Узнать, как проявит себя ваш SSD-накопитель на актуальной сборке, получится лишь на практике. С другой стороны, даже SATA-SSD A400 хватает для быстрой и комфортной работы в качестве системного диска, а ощутить разницу с NVMe в прикладных задачах не так и просто.
Но объективная оценка и субъективное восприятие скорости работы системы и отдельных приложений – это тема отдельного материала. Например, сравнения Windows и Linux по части требовательности к ресурсам аппаратных компонентов и более внимательным сравнением нагрузки на дисковую подсистему. А заодно можно будет сравнить важность системных драйверов для SSD и их влияние на итоговые результаты. Подопытные для наших тестов уже под рукой, о результатах расскажем совсем скоро.
Что такое KIWY? Kingston Is With You — Kingston всегда с вами.
Продукция, решения и технологии Kingston широко применяются и используются по всему миру корпорациями, центрами обработки данных и обычными людьми каждый день – от авиации и космических станций до смартфонов, ПК и фоторамок. Самые неожиданные сферы использования решений Kingston узнайте тут.
Для получения дополнительной информации о продуктах Kingston обращайтесь на официальный сайт компании.
Гибридные тесты
самая вкусная часть:
(внимание! Ошибётесь буквой диска — останетесь без данных)
Во время теста мы видим что-то вроде такого:
В квадратных скобках — цифры 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 куда более подходящий вариант для теста.
В посте собран перечень 20 лучших бесплатных инструментов разбивки, диагностики, шифрования, восстановления, клонирования, форматирования дисков. Вообщем практически все что нужно для базовой работы с ними.
1. TestDisk
TestDisk позволяет восстанавливать загрузочные разделы, удаленные разделы, фиксировать поврежденные таблицы разделов и восстанавливать данные, а также создавать копии файлов с удаленных/недоступных разделов.
Примечание: PhotoRec ето связанное с TestDisk приложением. С его помощью возможно восстановить данные в памяти цифровой камеры на жестких дисках и компакт-дисках. Кроме того можно восстановить основные форматы изображений, аудиофайлы, текстовые документы, HTML-файлы и различные архивы.
При запуске TestDisk предоставляется список разделов жесткого диска, с которыми можно работать. Выбор доступных действий, осуществляемых в разделах, включает: анализ для корректировки структуры (и последующее восстановление, в случае обнаружения проблемы); изменение дисковой геометрии; удаление всех данных в таблице разделов; восстановление загрузочного раздела; перечисление и копирование файлов; восстановление удаленных файлов; создание снапшота раздела.
2. EaseUS Partition Master
EaseUS Partition Master — инструмент для работы с разделами жесткого диска. Он позволяет создавать, перемещать, объединять, разделять, форматировать, изменяя их размер и расположение без потери данных. Также помогает восстанавливать удаленные или потерянные данные, проверять разделы, перемещать ОС на другой HDD/SSD и т.д.
Слева представлен перечень операций, которые можно выполнить с выбранным разделом.
3. WinDirStat
Бесплатная программа WinDirStat проводит анализ использованного места на диске. Демонстрирует, как данные распределяются и какие из них занимают больше места.
Клик по полю в диаграмме выведет на экран рассматриваемый файл в структурном виде.
После загрузки WinDirStat и выбора дисков для анализа, программа сканирует дерево каталога и предоставляет статистику в таких вариантах: список каталогов; карта каталогов; список расширений.
4. Clonezilla
Clonezilla создает образ диска с инструментом клонирования, который также упакован с Parted Magic и первоначально доступен, как автономный инструмент. Представлен в двух версиях: Clonezilla Live и Clonezilla SE (Server Edition).
Clonezilla Live является загрузочным дистрибутивом Linux, позволяющим клонировать отдельные устройства.
Clonezilla SE — это пакет, который устанавливается на дистрибутиве Linux. Он используется для одновременного клонирования множества компьютеров по сети.
5. OSFMount
Использование данной утилиты дает возможность монтировать ранее сделанные образы дисков и представлять их в виде виртуальных приводов, непосредственно просмотривая сами данные. OSFMount поддерживает файлы образов, такие как: DD, ISO, BIN, IMG, DD, 00n, NRG, SDI, AFF, AFM, AFD и VMDK.
Дополнительная функция OSFMount — создание RAM-дисков, находящихся в оперативной памяти компьютера, что существенно ускоряет работу с ними. Для запуска процесса нужно перейти в File > Mount new virtual disk.
6. Defraggler
Defraggler — бесплатная программа для дефрагментации жесткого диска, которая способствует увеличению его скорости и срока службы. Особенностью программы является возможность дефрагментации также и отдельных файлов.
Поддерживает файловые системы NTFS, FAT32 и exFAT.
7. SSDLife
SSDLife — проводит диагностику твердотельного диска, выводит на экран информацию о его состоянии и оценивает предполагаемый срок службы. Поддерживает удаленный мониторинг, управляет уровнем производительности на некоторых моделях жестких дисков.
Благодаря контролю износа SSD можно повысить уровень безопасности данных, вовремя выявлять проблемы. На основе анализа программа делает вывод насколько часто используется твердотельный диск.
8. Darik’s Boot And Nuke (DBAN)
Довольно популярная бесплатная утилита DBAN, применяется для очистки жестких дисков.
В DBAN два основных режима: интерактивный (interactive mode) и автоматический (аutomatic mode). Интерактивный режим позволяет подготовить диск к удалнию данных и выбирать необходимые опции стирания. Автоматический режим очищает все обнаруженные диски.
9. HD Tune
Утилита HD Tune предназначена для работы с жестким диском и SSD. Измеряет уровень чтения-записи HDD/SSD, сканирует ошибки, проверяет состояние диска и выводит на экран информацию о нем.
При запуске приложения, нужно выбрать диск из выпадающего списка и перейти к надлежащей вкладке, чтобы просмотреть информацию.
10. VeraCrypt
VeraCrypt — бесплатное приложение для шифрования с открытым исходным кодом. Используется шифрование на лету.
Проект VeraCrypt создался на основе TrueCrypt с целью усиления методов защиты ключей шифрования.
11. CrystalDiskInfo
CrystalDiskInfo отображает состояние жестких дисков, поддерживающих технологию S.M.A.R.T. Утилита проводит мониторинг, оценивает общее состояние и отображает детальную информацию о жестких дисках (версия прошивки, серийный номер, стандарт, интерфейс, общее время работы и т. д.). У CrystalDiskInfo есть поддержка внешних жестких дисков.
В верхней панели на экране отображаются все активные жесткие диски. Щелчок по каждому из них показывает информацию. Иконки Health Status и Temperature меняют цвет в зависимости от значения.
12. Recuva
Утилита Recuva служит для восстановления случайно удаленных или потерянных файлов. Она сканирует нужный носитель информации, после чего выводит на экран список удаленных файлов. Каждый файл имеет свои параметры (имя, тип, путь, вероятность восстановления, состояние).
Необходимые файлы определяются с помощью функции предпросмотра и отмечаются флажками. Результат поиска можно отсортировать по типу (графика, музыка, документы, видео, архивы) и сразу просмотреть содержимое.
13. TreeSize
Программа TreeSize показывает дерево находящихся на жестком диске директорий с предоставлением информации об их размерах, а также проводит анализ использования дискового пространства.
Размеры папок выводятся на экран от самых больших до самых маленьких. Таким образом становится понятно, какие папки занимают большую часть места.
Примечание: При наличии Defraggler, Recuva и TreeSize, можно инициировать функции Defraggler и Recuva для определенной папки непосредственно из TreeSize — все три приложения эффективно интегрируются.
14. HDDScan
HDDScan — утилита диагностики жесткого диска, используется для тестирования накопителей информации (HDD, RAID, Flash) с целью выявления ошибок. Просматривает S.M.A.R.T. атрибуты, выводит показания датчиков температуры жестких дисков в панель задач и выполняет сравнительный тест чтения-записи.
HDDScan предназначена для тестирования накопителей SATA, IDE, SCSI, USB, FifeWire (IEEE 1394).
15. Disk2vhd
Бесплатная утилита Disk2vhd преобразует действующую физический диск в виртуальный Virtual Hard Disk (VHD) для платформы Microsoft Hyper-V. Причем, VHD-образ можно создавать прямо с запущенной операционной системы.
Disk2vhd создает один VHD-файл для каждого диска с избранными томами, сохраняя информацию о разделах диска и копируя только те данные, которые относятся к выбранному тому.
16. NTFSWalker
Портативная утилита NTFSWalker позволяет проводить анализ всех записей (включая и удаленные данные) в главной файловой таблице MFT диска NTFS.
Наличие собственных драйверов NTFS дает возможность просматривать файловую структуру без помощи Windows на любых носителях чтения компьютера. К просмотру доступны удаленные файлы, обычные файлы, а также подробные атрибуты для каждого файла.
17. GParted
GParted — редактор дисковых разделов с открытым исходным кодом. Осуществляет эффективное и безопасное управление разделами (создание, удаление, изменение размера, перемещение, копирование, проверка) без потери данных.
GParted позволяет создавать таблицы разделов (MS-DOS или GPT), включать, отключать и изменять атрибуты, выравнивать разделы, восстанавливать данные с поврежденных разделов и многое другое.
18. SpeedFan
Компьютерная программа SpeedFan следит за показателями датчиков материнской платы, видеокарты и жёстких дисков, с возможностью регулирования скорости вращения установленных вентиляторов. Есть возможность проводить автоматическую и ручную регулировку.
SpeedFan работает с жесткими дисками с интерфейсом SATA, EIDE и SCSI.
19. MyDefrag
MyDefrag — бесплатный дисковой дефрагментатор, который используется для упорядочивания данных, размещенных на жестких дисках, дискетах, дисках USB и картах памяти.
У программы есть удобная функция работы в режиме скринсейвера, в результате чего дефрагментация будет производится во время, назначенное для запуска хранителя экрана. MyDefrag также позволяет создавать или настраивать собственные сценарии.
20. DiskCryptor
С помощью шифровальной программы DiskCryptor с открытым исходным кодом, можно полностью зашифровать диск (все дисковые разделы, включая системный).
У DiskCryptor довольно высокая производительность — это один из самых быстрых драйверов шифрования дисковых томов. Программа поддерживает FAT12, FAT16, FAT32, NTFS и exFAT файловые системы, позволяя шифровать внутренние или внешние диски.
Привет, Хабр! Любой, кто хоть раз сталкивался с неожиданной смертью флешки, жесткого диска или SSD-накопителя, расскажет вам, насколько важно отслеживать SMART-параметры и замерять скорость в бенчмарках. Независимо от системы. И если с Windows достаточно вбить в поиске CrystalMark, то пользователям Linux подобный лайфхак не подойдет. Зато подойдет этот текст, где вся история пропитана поисками.
Проверка скорости чтения диска
Проще всего измерить скорость диска с помощью программы hdparm. Установить ее очень просто:
Теперь нужно вывести список дисков и разделов в системе:
Выбираем нужный раздел и проверяем скорость чтения:
Обращаю ваше внимание еще раз на то, что мы видим очень примерные цифры, которые имеют значение только в сравнении с другими цифрами, полученными в схожих условиях. hdparm выполняет последовательное чтение с диска. В реально работе скорость чтения диска будет другой.
Почему память не вечна?
Углубляться в физику производства чипов памяти и объем работ по литографии — удел отдельных энциклопедических записей. Нам достаточно вспомнить, как сильно нагревались некоторые металлические USB-флешки при записи больших архивов. Это было горячо, но многие твердотельные накопители работают без остановки, при температурах свыше 70°С. Ожидать, что такая нагрузка не скажется на долговечности SSD–накопителя, весьма опрометчиво.
За реальным примером износа далеко идти не нужно. В работающем 24/7 ноутбуке, заводской конфиг изначально включал лишь медленный жесткий диск. Пустой M.2 слот был заполнен самым доступным SSD на 240 Гигов, исправно служащим и по сей день в роли системного. С момента покупки прошло уже два года, а по данным CrystalDiskInfo остаток ресурса составляет всего 87%.
По ошибкам – критических значений пока не выявлено, но куда интереснее информация, полученная при запущенном фоном бенчмарке CrystalDiskMark. Результаты измерения скорости при стандартных значениях ячеек и объема данных вполне соответствуют SATA-SSD. Но температура платы достигала 70°С в пиковые моменты, что много для чипов памяти. Тем более, этот M.2–накопитель установлен в адаптере под слот форм-фактора 2.5”.
На скриншоте температуры системного диска вы могли заметить второй, существенно более холодный носитель. Это представитель бюджетной линейки NVMe PCIe SSD-накопителей в форм-факторе M.2, поддерживающий до 4-х линий по шине PCIe Gen 3.0. Всего в линейке есть три разновидности по объему: 250, 500 и 1000 ГБ, но младшая ограничена по скорости чтения и записи. Поэтому выгоднее брать одну из старших, как 500 ГБ модификацию в данном случае. Кстати, а как она себя проявит под нагрузкой?
До 60°С Kingston A2000 подобрался буквально пару раз при выполнении тестов на чтение. А вот запись сумела разогреть его до 69°С без особых проблем. Со второго прогона, выставив размер файла 0.5 ГБ, диск показал практически паспорт. Этот M.2-накопитель приобретался как раз для переноса на него системы Windows, но прежде стало интересно взглянуть, какие ощущения подарит работа операционной системы на быстром 2-х гигабайтном NVMe–накопителе, и насколько велика окажется разница в сравнении с диском SATA.
А для этого на свежий Kingston A2000 была установлена актуальная версия Ubuntu, скачанная с официального сайта и смонтированная на USB–флешку.
Читайте также: