Среднее время ответа жесткого диска
С характеристиками производительности жёстких дисков вы уже встречались в разделе 4.2.4 Жёсткие диски, в этом разделе этот вопрос будет рассмотрен подробнее. Для системных администраторов важно понимать, что, не имея как минимум поверхностных знаний о принципах работы жёстких дисков, можно неосмотрительно изменить конфигурацию компьютера так, что это может негативно повлиять на производительность.
Время, которое требуется жёсткому диску для ответа на запрос ввода/вывода и для его завершения зависит от двух факторов:
физических и механических ограничений жёсткого диска
создаваемой системой нагрузки.
Эти аспекты производительности подробно рассматриваются в следующих разделах.
тесты на чтение
Запуск: fio read.ini
Содержимое read.ini
Задача подобрать такой iodepth, чтобы avg.latency была меньше 10мс.
5.4.1.2. Головки чтения/записи данных
Головки чтения/записи работают только при вращении пластин, над которыми они «парят». Так как чтение и запись данных возможно только при перемещении носителя под головками, время, необходимое для того, чтобы нужный сектор полностью прошёл под головкой, в значительной мере определяет вклад, который вносит головка в общее время доступа. Для диска с 10 000 оборотов/мин и 700 секторами на дорожке это время в среднем составляет 0,0086 миллисекунд.
Также причиной тормозов может быть и неисправность жесткого диска
Посыпавшийся жесткий диск будет работать гораздо медленнее исправного, поэтому также желательно проверить и его здоровье. Благо, каждый диск умеет проводить самодиагностику - S.M.A.R.T. Так что все, что нам нужно - просто считать данные из этого файла, после чего сделать выводы.
Близкий к мертвому HDD во время тестирования Victoria. Кстати, полностью сканировать диск она умеет не только из-под DOS, но и из-под виндовс
Близкий к мертвому HDD во время тестирования Victoria. Кстати, полностью сканировать диск она умеет не только из-под DOS, но и из-под виндовс
Самой простой является утилита CrystalDiskInfo, которая показывает состояние диска прямо из-под ОС. В то же время, она не очень информативна - можно только просмотреть значения.
Для более детальной диагностики, нужно установить на чистую флешку утилиту HDD Victoria, а после в биосе (или уефи) выставить загрузку с флешки. Проверка займет довольно продолжительное время, однако программа делает опрос каждого сектора диска в реальном времени. И вот она уже даст более детальную картину здоровья жесткого диска. Хотя, как говорил выше, можно и из-под системы этой прогой просканировать диск.
К примеру, если много секторов с долгим откликом, но которые все-таки отвечают, то это не очень хороший признак, но в SMART такие сектора помечаются как "OK", поскольку. Ну, они же ответили.
Если статья понравилась - не забудь поставить лайк, подписаться на канал , а также на нашу группу ВК . До скорого!
Испытателя-обозревателя жестких дисков и всякой флеши хлебом не корми, а дай позапускать какой-нибудь навороченный специфический бенчмарк, который покажет, сколько «попугаев» производительности или «ио-псов» та или иная модель покажет в нем. Всякие «иометры», «писимарки» и прочие «йо!-марки», как правило, специально спроектированы, чтобы наилучшим образом продемонстрировать разницу между дисками при тех или иных операциях непосредственно с этими дисками. И они (бенчмарки и обозреватели :)) со своим предназначением прекрасно справляются, давая нам, читателям, богатую пищу для размышлений, какую модель диска предпочесть в том или ином случае.
Но дисковые бенчмарки (да и обозреватели!) мало что говорят простому пользователю о том, как именно (и насколько) улучшится (или ухудшится) комфортность его повседневной работы с персональным компьютером, если тот или иной диск будет установлен в его систему. Да, мы будем знать, что, например, в два раза быстрее файл/директория в идеальных условиях запишется на наш диск или прочтется с него, или, скажем, на 15% быстрее станет выполняться «загрузка Выньдовс» — а точнее не она сама, на нашем конкретном компьютере, а ранее записанный на каком-то другом, совсем непонятном нам и, как правило, уже морально устаревшем ПК, специальный паттерн, который к нашему любимому ПК может иметь весьма далекое отношение. Допустим, погонимся мы за новенькой дорогой моделью диска, начитавшись всяких «авторитетных» обозревателей, потратимся, а придем домой и ровным счетом ничего, кроме сознания того, что купили крутую по чьему-то субъективному мнению вещицу, не почувствуем… То есть наш ПК как «бегал», так и продолжает «бегать», «летать» он отнюдь не стал. :)
А все дело в том, что в реальности «отдача» от быстродействия дисковой подсистемы, как правило, ощутимо маскируется отнюдь не мгновенной работой остальных подсистем нашего компьютера. В результате, даже если мы поставим втрое более шустрый (по профильным бенчмаркам) винчестер, наш компьютер в среднем по ощущениям в три раза быстрее работать вовсе не станет, и субъективно мы в лучшем случае почувствуем, что совсем чуток быстрее стали запускаться графический редактор и любимая игрушка. Этого ли мы ждали от апгрейда?
В этой небольшой статье мы, отнюдь не претендуя на всеобъемлющую полноту освещения этого многогранного вопроса, попробуем дать ответ на то, чего же все-таки в реальности ждать от дисковой подсистемы с той или иной «реперной» производительностью. Надеемся, что это позволит вдумчивому читателю сориентироваться в предмете и решить, когда и сколько тратить на очередной накопитель на «очень жестких» дисках.
Тестовые конфигурации
Для первых опытов мы выбрали две базовые системные конфигурации десктопов. Первая из них основана на одном из самых производительных «настольных» процессоров Intel Core i7-975, а вторая — на младшем (на момент написания статьи) десктопном процессоре из линейки Intel Core i3 — модели i3-530 ценой чуть выше 100 долларов. Таким образом, мы проверим влияние скорости дисковой подсистемы как для топового ПК, так и для недорогого современного десктопа. Производительность последнего, кстати, вполне сравнима с таковой для современных топовых ноутбуков, поэтому мы заодно с «двумя зайцами» «убиваем» и третьего. :) Конкретные конфигурации выглядели так:
- процессор Intel Core i7-975 (HT и Turbo Boost активированы);
- материнская плата ASUS P6T на чипсете Intel X58 с ICH10R;
- 6 Гбайт трехканальной памяти DDR3-1333 (тайминги 7-7-7);
- видеоускоритель AMD Radeon HD 5770.
- процессор Intel Core i3-530 (2 ядра + НТ, 2,93 ГГц);
- материнская плата Biostar TH55XE (чипсет Intel H55);
- 4 Гбайт двухканальной памяти DDR3-1333 (тайминги 7-7-7);
- видеоускоритель AMD Radeon HD 5770.
- типичный SATA SSD на MLC-памяти (≈250 Мбайт/с на чтение, ≈200 Мбайт/с на запись);
- типичный 3,5-дюймовый SATA-«семитысячник» на 1 Тбайт (≈150 Мбайт/с на чтение/запись);
- быстрый 2,5-дюймовый SATA-«семитысячник» на 500 Гбайт (≈100 Мбайт/с на чтение/запись);
- SATA-«семитысячник» малой емкости со скоростью чтения/записи в районе 50 Мбайт/с;
- ноутбучный SATA-«пятитысячник» со скоростью чтения/записи в районе 50 Мбайт/с.
- Patriot TorqX PFZ128GS25SSD (IDX MLC SSD 128 Гбайт);
- Hitachi Deskstar 7K1000.C HDS721010CLA332 (1 Тбайт);
- Seagate Momentus 7200.4 ST950042AS (500 Гбайт);
- Hitachi Travelstar 7K100 HTS721010G9SA00 (100 Гбайт);
- Toshiba MK1246GSX (5400 об/мин, 120 Гбайт).
Подчеркнем, что наши тестовые конфигурации не нацелены на оценку влияния данных конкретных (примененных нами в этих тестах) моделей жестких дисков, но эти конфигурации фактически представляют «интересы» не только тех или иных десктопов, но также (опосредованно) медиацентров, мини-ПК и мощных ноутбуков. И пусть использованная нами модель видеокарты вас не смущает — подавляющее большинство из демонстрируемых нами здесь результатов бенчмарков несущественно зависит (или вовсе не зависит) от производительности видеоускорителя.
Методология
К сожалению, SYSmark 2007 Preview вышел уже давно и хотя он регулярно патчился производителем (мы здесь используем версию 1.06 за июль 2009 г.), в своей основе содержит приложения отнюдь не самые свежие, образца примерно 2005 г. Но сами-то мы всегда ли «юзаем» самые последние версии программ? Многие, например, еще на Windows XP себя очень даже комфортно чувствуют (и даже тестируют новое железо под ней!), уже не говоря о том, что не воодушевлены многосотдолларовой «гонкой офисных вооружений», по сути, навязываемой нам одной небезызвестной редмонтской компанией. Таким образом, можно считать, что SYSmark 2007 до сих пор актуален для «среднестатистического» пользователя ПК, тем более что мы здесь запускаем его на последней ОС — Windows 7 Ultimate x64. Ну а компании BAPCo нам остается пожелать поскорее преодолеть последствия финансового кризиса в ИТ-индустрии и выпустить новую версию SYSmark на базе приложений образца 2010-2011 гг.
По результатам тестов SYSmark 2007 Preview в целом и по его подтестам E-Learning, VideoCreation, Productivity и 3D, которые мы в данном случае провели для двух современных системных конфигураций ПК (на базе процессоров Intel Core i7 и i3) и пяти «реперных» накопителей разной «дисковой» производительности (то есть всего 10 протестированных систем), мы в этой статье сделаем выводы о том, как сильно тот или иной диск будет влиять на комфортность работы пользователя с ПК, то есть как сильно изменится среднее время реакции компьютера на действия активного пользователя.
Но одним SYSmark мы, конечно же, не ограничимся. Помимо проверки «дискозависимости» некоторых отдельных приложений, тестов и комплексных бенчмарков, мы «присовокупим» к оценкам влияния диска на общесистемную производительность показатели системных тестов более ли менее современного пакета Futuremark PCMark Vantage. Хотя подход PCMark и более синтетический, нежели у SYSmark, тем не менее, он в различных паттернах также измеряет скорость работы «целиком» компьютера в типичных пользовательских задачах, причем при этом учитывается и производительность дисковой подсистемы (о детальном устройстве PCMark Vantage тоже написано предостаточно, поэтому вдаваться в подробности здесь не станем). Попробовали мы привлечь и новенький (этого года) интеловский тест (HDxPRT 2010). Он отчасти напоминает по подходу SYSmark, но применительно к работе с мультимедийным контентом, хотя и оценивает не среднее время реакции пользователя, а общее время выполнения того или иного комплексного сценария. Однако дискозависимость этого теста оказалась самой минимальной (почти отсутствующей) и совершенно непоказательной, поэтому «прогнали» мы этот длительный бенчмарк не для всех конфигураций, и его результаты в этой статье не демонстрируем.
Интерфейс подключения
Тут все тоже очень просто: интерфейс SATA 3 имеет полную совместимость с интерфейсом SATA 2, то есть диск с 3-й версией подключить к разъему второй версии - можно. В случае с жесткими дисками - не критично, ибо нынешние устройства только-только подбираются к пределам возможностей интерфейса IDE (150 мб/с, фактически меньше - около 120-130 мб/с, так что можно сказать, что его мы таки преодолели).
Но вот в случае с SSD - обязательно нужно подключать его к последней версии SATA, поскольку скорость SATA SSD уже подошла к пределам разъема SATA 3. При подключении к SATA 2 мы получим его предельную скорость, которая, в то же время, будет меньше предельной скорости работы SSD.
Однако зачастую, вызвать конкретные тормоза это не сможет. У нас упадет скорость работы, фактически - вдвое, но это все еще быстрее, чем почти все традиционные жесткие диски (покажите мне диск для ПК с интерфейсом SATA 3, который бы уперся в предел возможностей SATA 2 - это около 250 мб/с). Но если нужна скорость, то лучше все-таки подключить SSD к соответствующему порту.
Для этого нужно найти SATA 3 порты, они обычно как-то выделены на фоне остальных, например - имеют другой цвет, или расположены в другом месте. Некоторые говорят, что для этого нужен и SATA 3 кабель, но так как они полностью идентичны, при подключении SATA 3-SATA 3 через кабель SATA 2, скорость поменяться не должна. Хотя это может зависеть от каждого конкретного кабеля, но у меня с этим проблем не было.
5.4.2.2. Количество клиентов
Нагрузка жёсткого диска, который обрабатывает запросы ввода/вывода, поступающие от нескольких источников, отличается от нагрузки жёсткого диска с всего лишь одним источником запросов. Основная причина этого состоит в том, что несколько клиентов диска могут создать большую нагрузку, чем один единственный клиент.
Объясняется это тем, что прежде чем клиент сможет послать очередной запрос, он должен выполнить некоторые действия. Помимо прочего, чтобы запрос мог быть выполнен, клиент должен его сформировать, а так как на это формирование уходит некоторое время, нагрузка, которую может создать один клиент, имеет верхний предел, и чтобы её увеличить, нужен более быстрый процессор. Этот предел становится ещё более явным, если клиент обращается к диску, обрабатывая данные, вводимые человеком.
Однако, несколько клиентов могут создать большие нагрузки. Пока мощности процессора достаточно для вычислений, необходимых для формирования запросов к диску, увеличение числа клиентов приводит к увеличению общей нагрузки.
Однако есть и ещё один фактор, оказывающий влияние на общую нагрузку. Он обсуждается в следующем разделе.
От чего может тормозить SSD?
Способов замедлить диск достаточно много, но выделю основные: неправильный режим работы, интерфейс подключения, частое обращение системы к диску. Разберемся с каждым из них.
Заключение
Наше первое исследование дискозависимости общесистемной производительности современных ПК топового и среднего уровней на примере десятка реперных конфигураций показало, что в большинстве традиционных задач простой пользователь вряд ли почувствует (по своим ощущениям от работы компьютера) большую разницу от применения более быстрого или более медленного диска из тех, что сейчас представлены на рынке или продавались не так давно. В большинстве задач, не связанных напрямую с постоянной активной работой с диском (копирование, запись и чтение большого объема файлов на предельной скорости), дискозависимость системной производительности либо отсутствует вовсе, либо не настолько велика, чтобы мы ее реально почувствовали (ощутили) по уменьшению среднего времени отклика системы на наши действия. С другой стороны, безусловно, существует немало задач (например, обработка видео, профессиональная работа с фото и пр.), в которых дискозависимость заметна. И в этом случае применение высокопроизводительных дисков и, в частности, SSD, способно положительно повлиять на наши ощущения от работы ПК. Но шустрый диск и SSD — это не панацея. Если ваш компьютер работает недостаточно быстро, то к апгрейду имеет смысл подходить строго в соответствии с теми задачами, которые при помощи этого ПК предполагается решать. Чтобы вдруг не испытать разочарования от потраченных без реальной пользы денег.
Гибридные тесты
самая вкусная часть:
(внимание! Ошибётесь буквой диска — останетесь без данных)
Во время теста мы видим что-то вроде такого:
В квадратных скобках — цифры 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 куда более подходящий вариант для теста.
Вирусов никаких нет 100%. Стоит Eset Internet Security лицензия.
Как быть в этом случае? Переустановка винды? Новый HDD? Или что?
- Вопрос задан более трёх лет назад
- 14202 просмотра
Простой 4 комментария
sergeevpetro, ничего страшного, запусти стандартную проверку диска.
И заодним, посмотри режим работы контроллера к которому подключен диск, именно так происходит на дисках которые сваливаются в режим PIO. Лечится опять же, проверкой диска, кабеля данных, или переустановкой диска -
удалить диск, перезагрузиться, он найдётся и всё станет хорошо.
На скриншоте Victoria четко видно 5 ремапов. Значит диск разваливается, наверняка и кандидатов в ремапы немало.
Сохраняйте ценную информацию и меняйте диск.
э. с какой стати "ремапы" означают разваливающийся диск?
вот так, по обрывкам скриншотов, ставить диагноз О_о это тоже диагноз.
Процесс разрушения поверхности уже идет и ремапы тому свидетельство. Следовательно, доверять этому диску в плане надежности нельзя.
Я бы согласился, что диагноз по скриншотам ставить нельзя, но здесь картина очень ясная.
ReSupport, ремап не обязательно указывает на то что диск разваливается. Это лишь говорит, что шансы на то что диск откажет стали выше. У меня куча дисков с ремапами работает годами и сейчас продолжает работать.
burst, там не только ремапы. Там и двухсотники и пятисотники и даже полторы секунды есть. На диске явно существует дефект и он прогрессирует. Все ценные данные с такого диска лучше убрать.
CityCat4, это ноутбучный винт, изредка появляющиеся блоки с задержкой в 200 мс - норма для них.
А уж какое-то "прогрессирование" на 1+1 по полсекунды и полторы - фигня.
И на SMART-e у него там тупо "залипли" сектора, чаще всего это просто софтовая проблема.
Не помешает проверить наличие места на системном диске - если его там мало, то винда начнет нещадно тормозить.
А в общем ReSupport прав - нужно подумать про замену диска и побыстрее.
Поверхность диска повреждена. В теории, он в таком состоянии может проработать долго, а может нагнуться в течение двух дней. По-хорошему -- надо бэкапить данные и менять диск.
Дефрагментацию диска провести. И устранить всякую стороннюю хрень, дергающую диск туда-сюда. Если не поможет, заменить (в идеале - на SSD). ABD серия тошиб имеет NAND кеш внутри. Может даже он износился и мешается.
Безотносительно к остальным проблемам, которые могут быть, окончательным решением вопроса с тормозами любого ноутбука является лишь замена тормознейшего по определению HDD 5400 rpm на нормальный SSD (в совокупности с добиванием памяти до максимума, т.к. у вас 4 Гб, это НИЧТО, поэтому всё, что можно, постоянно свопится на тормозной НЖМД, что только усугубляет тормоза).
Без этого все равно будет гарантированно тормозить.
John Smith, дооо!
И плевать, что есть понятия - достаточность, соответствие задачам, бюджет, энергоэффективность наконец (и прочая, и прочая).
Всем привет, дорогие друзья. Рад вас видеть! Сегодня я расскажу о нескольких способах, как сделать свой SSD медленнее. Ну это так, шутка. На самом деле, проверить несколько пунктов следует всем, чтобы убедиться, что ваш SSD работает на максимальной скорости. Давайте начнем по порядку.
Статья также актуальна и для владельцев обычных HDD (для них - даже более актуальна). Эта статья не для ПК-профи, а для несведущих, которые не знают элементарных вещей.
5.4.2.1. Отношение операций чтения и записи
Для среднего жёсткого диска, в котором данные хранятся на магнитном носителе, отношение числа операций чтения к число операций записи не имеет большого значения, так как и чтение, и запись выполняется одинаковое время [1] . Однако, в других технологиях хранения на выполнение чтения и записи требуется разное время [2] .
Вследствие этого, устройства, у которых скорость записи ниже скорости чтения (например), способны выполнять меньше операций записи, чем чтения. Также можно сказать, что на операцию записи устройство расходует больше потенциала обработки запросов, чем на операцию чтения.
Быстродействие собственно накопителей
Прежде чем перейти к результатам нашего исследования дискозависимости системной производительности, кинем краткий взгляд на быстродействие самих накопителей, которое мы оценивали нашим традиционным способом — при помощи профильных дисковых бенчмарков. Средняя скорость случайного доступа к этим дискам показана на следующей диаграмме.
Понятно, что SSD вне досягаемости с типичными для себя 0,09 мс, десктопный «семитысячник» чуть шустрее шевелит «усами», чем ноутбучные «семитысячники», хотя, например, модель Hitachi 7K100 по среднему времени доступа может посоперничать с рядом 3,5-дюймовых «семитысячников» прошлых лет, имеющих сходную емкость и скорость линейного доступа. Последняя для наших реперных дисков приведена на следующей диаграмме.
«Пятитысячник» от Toshiba по этому параметру чуть быстрее, чем «семитысячник» Hitachi 7K100, однако уступает последнему по времени случайного доступа. Посмотрим, что окажется важнее для типичной работы десктопа и есть ли реальная разница от применения этих дисков, по сути, разных классов.
В качестве любопытной информации попутно приведем показатель, которым Windows 7 встроенным «в себя» бенчмарком оценивает полезность того или иного реперного накопителя.
Подчеркнем, что для обеих тестовых систем Windows 7 оценила видеоускоритель HD 5770 на 7,4 балла (по графике и игровой графике), а процессор и память получили оценки, соответственно, 7,6 и 7,9 для старшей и 6,9 и 7,3 для младшей из наших тестовых систем. Таким образом, диски — это самое слабое звено данных систем (по «мнению» Windows 7). Тем более заметным, по идее, должно быть их влияние на общесистемную производительность ПК.
Последней в этом параграфе будет диаграмма с результатами сугубо дисковых тестов PCMark Vantage, показывающая типичную диспозицию выбранных накопителей в традиционных обзорах жестких дисков, где подобными тестами оперируют обозреватели для вынесения своего сурового вердикта.
Более чем пятикратное преимущество SSD над НЖМД в этом конкретном бенчмарке (PCMark Vantage, HDD Score) — эти типичное положение на данный момент (впрочем, в ряде других десктопных бенчмарков разрыв все же поменьше). К слову, обратите внимание, что результаты дисковых тестов крайне слабо зависят от системной конфигурации — они примерно одинаковы для процессоров, в 10 раз отличающихся друг от друга по цене, а также в пределах погрешности одинаковы для x64- и x86-случаев. Кроме этого, отметим, что старший из выбранных нами НЖМД опережает младший по «чисто дисковой» производительности примерно вдвое. Посмотрим, как этот разрыв в 5-10 раз по дисковым бенчмаркам скажется на реальной работе ПК.
5.4.2. Нагрузка диска и производительность
Ещё один фактор, влияющий на производительность жёсткого диска — нагрузка этого диска. Нагрузка диска имеет свои характеристики, в частности:
Отношение объёма чтения к объёму записи
Число активных клиентов диска
Ограниченность области чтения/записи
Эти факторы рассматриваются подробно в следующих разделах.
Загрузка диска на 100%
Это - самая распространенная проблема, с которой, с большой вероятность, сталкивались многие из вас. Дело в том, что винда - система сложная, поэтому тут периодически вылезают какие-либо баги, которые грузят железо компьютера.
Прежде всего, нужно открыть диспетчер задач, чтобы понять - какой конкретно процесс загружает диск. Как только виновник найден, существует два пути:
Завершить процесс . Подойдет в том случае, если, например, антивирус начал проверку, и в других случаях, когда такое поведение компьютера встречается впервые (или происходит редко). В этом случае мы решаем проблему в данный момент, но нет никаких гарантий на то, что проблема снова не появится в будущем.
Второй вариант . Удаляем файл, который грузит диск. В диспетчере устройств находим процесс, который грузит диск. Щелкаем ПКМ по нему, затем открываем расположение файла. Открывается папка, в которой уже выбран тот файл, что в данный момент выбран нами в диспетчере задач.
Теперь смотрим, что это за файл, в интернете, если это какой-то системный файл. Забегая вперед, скажу, что системные файлы удалять нельзя, и единственным выходом будет исправление ошибки. Если же систему грузит какой-то не особо важный файл, то его вполне можно и удалить, при условии, что этот файл - точно не повлияет на работу системы, то есть не является системным.
Но даже так, прежде чем удалять - надо разобраться в том, почему именно диск нагружается, поскольку нагрузка диска может быть и признаком вирусной тусовки на вашем компьютере. Всех случаев 100% загрузки диска в одной статье я не напишу, поэтому форма выглядит так: "*имя процесса* грузит диск на 100%". Нажимаем "поиск в Google, натыкаемся нна статьи, которые посвящена каждому отдельному случаю, коих очень немало.
5.4.1.1. Время обработки команды
Во всех выпускаемых сегодня жёстких дисках встроены сложные компьютерные системы, управляющие их работой. Эти компьютерные системы выполняют следующие задачи:
взаимодействие с внешним миром через интерфейс жёсткого диска
управление работой остальных компонентов жёсткого диска и восстановление в случае различных ошибок, которые могут возникнуть
обработка низкоуровневых данных, считываемых или записываемых на носитель хранилища
И хотя в жёстких дисках используются довольно мощные микропроцессоры, они выполняют свои задачи в течение какого-то времени. В среднем это время составляет порядка 0,003 миллисекунд.
5.4.1.3. Задержка, вызванная вращением
Так как пластины диска крутятся постоянно, маловероятно, что в момент получения запроса ввода/вывода пластина будет находиться в той точке, в которой сразу можно обратиться к нужному сектору. Следовательно, даже если все остальные компоненты диска готовы обратиться к этому сектору, они должны ждать, пока под головкой не окажется нужный сектор вращающейся пластины.
Вот почему в высокоскоростных дисках обычно пластины диска вращаются обычно с большей скоростью. Сегодня скорость 15 000 оборотов/мин. имеют самые скоростные диски, тогда как для дисков начального уровня считается достаточной скорость 5 400 оборотов/мин. В среднем для диска 10 000 оборотов/мин. задержка составляет около 3 миллисекунд.
Режим работы
Режим работы контроллера очень сильно влияет на производительность дисков, особенно - когда к ним требуется частый доступ (например, при записи кучи маленьких файлов). Посмотреть режим контроллера можно в BIOS или UEFI, хотя на почти всех более-менее актуальных сегодня железках, он уже с завода стоит в верном положении.
Кстати о "положениях" - их всего два. IDE и AHCI. Как вы понимаете, IDE - не наш вариант. Он нужен для тех устройств, которые по каким-то причинам, не могут использовать AHCI, хотя таких я вообще еще не видел. В любом случае, этот режим - самый простой, а значит - может пригодиться для каких-нибудь отладочных работ.
В то же время, как следует из названия, в этом режиме диски функционируют со скоростью IDE, то есть - около 120-130 мб/с, что для SSD диска - критично. Еще критичнее - скорость чтения и записи массива мелких фалов, которая очень сильно страдает. А ведь это - вроде как главное преимущество SSD перед HDD, которое в данном случае - полностью нивелируется.
Результаты общесистемных тестов
Для начала — диаграмма с итоговым рейтингом всех 10 систем в тесте SYSmark 2007.
Как и «предрекал» нам индекс Windows 7, нет никакой практической разницы между системами с двумя младшими из выбранных нами реперных дисков, хотя это и диски разных классов (7200 и 5400 об/мин). Интересно и то, что производительные модели SATA-семитысячников форм-факторов 3,5 и 2,5 дюйма, причем различающиеся между собой вдвое по емкости (читай — на старшем примерно вдвое меньше перемещаются головки при выполнении одного и того же общесистемного теста), почти в полтора раза — по скорости линейно доступа и заметно — по скорости случайного доступа, так вот эти две модели в реальных ПК ведут себя практически одинаково, то есть вы при всем желании на своих «человеческих» ощущениях не почувствуете между такими системами никакой разницы в комфорте при типичной работе с приложениями. Зато после апгрейда на один из них с одной из наших младших реперных дисковых подсистем прибавка в среднем составит около 15% (напомним, что по чисто дисковой производительности они различаются примерно вдвое!). Это вполне актуальная ситуация и для ноутбука (замена устаревшего пятитысячника на емкий топовый семитысячник), и для десктопа (апгрейд старого семитысячника на новый терабайтник).
Но 15% — это много или мало? Автору этих строк думается, что это, на самом деле, очень мало! Фактически, это почти предел нашей дифференциации по ощущениям (≈1 дБ). Мы, как биологические индивиды, явно ощущаем разницу во времени протекания процессов (и воспринимаем разницу в других «аналоговых» величинах), если эта разница составляет хотя бы процентов 30-40 (это примерно соответствует 3 дБ логарифмической шкалы восприятия нами различных внешних раздражителей). В противном случае нам, в общем-то, все равно. :) А еще лучше, если разница по времени между процессами будет двукратная (6 дБ). Тогда мы точно скажем, что система/процесс явно ускорился. Но это, увы, далеко не случай показанной выше диаграммы с SYSmark 2007. Таким образом, если после апгрейда НЖМД вы не будете специально сидеть с секундомером в руке или гонять специализированные дисковые бенчмарки, то о прибавке комфортности своей работы вы вряд ли узнаете!
Чуть иной случай — с апгрейдом НЖМД на SSD. Тут уже в рамках старшей модели ноутбука, например, прибавка средней общесистемной производительности составит около 30%. Да, мы сможем это почувствовать. Но вряд ли при этом скажем, что система стала «летать». Даже в случае топового настольного ПК применение SSD вместо одного НЖМД даст нам лишь 20-40% уменьшения среднего времени реакции ПК на действия пользователя (это при 5-10-кратной разнице в скорости самих дисков!). Я отнюдь не хочу сказать, что на отдельных частных задачах, связанных с активным использованием диска, вы не скажете «вау!». Но в целом ситуация будет отнюдь не столько радужная, как порой описывается тестерами жестких дисков. Причем, применять SSD в слабеньких ПК, как мы видим из этой диаграммы, вряд ли очень целесообразно — средняя прибавка комфортности работы будет на уровне порога индивидуальной различимости. А наибольший эффект от SSD вы почувствуете в мощных ПК.
Впрочем, не все так уж грустно! Например, анализируя положение в разных паттернах SYSmark 2007, можно прийти к следующим выводам. Так, при выполнении задач определенного профиля (в данном случае, работа с 3D и сценарий E-Learning) действительно почти нет разницы, каким диском вы при этом пользуетесь (разница между нашим старшим и младшим реперами составляет «неразличимые» нами 5-15%). И здесь совсем нет смысла тратиться на новый быстрый диск! Однако с другой стороны, на ряде задач (в частности, сценарий VideoCreation, активно использующий редактирование видео и аудио) вы все же сможете почувствовать «ветерок в ушах»: для мощного десктопа сокращение среднего времени реакции ПК на действия пользователя от применения SSD может достигнуть заветных 2 раз (см. диаграмму ниже), да и для менее мощной десктопной системы, а также топового ноутбука польза от применения SSD в сценариях VideoCreation и Productivity совершенно очевидна (в VideoCreation, к слову, и топовые НЖМД ведут себя очень даже достойно). Таким образом, мы в очередной приходим к навязшему на зубах постулату: универсальных решений не существует, и конфигурацию своего ПК надо подбирать, руководствуясь тем, какие конкретные задачи вы на нем собираетесь решать.
Глупо отрицать очевидное — согласно методике оценки теста PCMark Vantage, преимущество систем с SSD неоспоримо и порой более чем двукратно по сравнению с младшими из наших реперных НЖМД (но все же не 10-кратно). А разница между быстрыми десктопным и ноутбучным винчестерами и здесь не так уж очевидна. И уж всяко неразличима в «реальности, данной нам», как известно, «в ощущениях». Оптимально в данном случае ориентироваться на «верхний» блок «PCMark» на этих диаграммах, показывающий «главный» индекс общесистемной производительности этого бенчмарка.
Да, можно спорить, что это в определенном смысле «синтетика», куда менее реалистичная, чем имитация работы пользователя в тестах типа SYSmark. Однако паттерны PCMark Vantage учитывают много таких нюансов, которые пока что отсутствуют в SYSmark. Поэтому тоже имеют право на жизнь. А истина, как известно «где-то рядом» (и этот перевод, как известно, неточен). :)
Замечания
На самом деле это не совсем так. Во всёх жёстких дисках есть какой-то объём интегрированной кэш-памяти, позволяющей увеличить скорость чтения. Однако, любой запрос на чтение данных может быть в конечном счёте удовлетворён только, когда данные физически считаются с носителя. Это значит, что хотя кэш может способствовать некоторому увеличению быстродействия, он никогда не сможет полностью исключить время, требуемое для физического чтения данных с носителя.
Это касается некоторых оптических дисков и объясняется физическими ограничениями технологий, применяемых при реализации оптических хранилищ данных.
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'а.
Тесты на запись
(внимание! Ошибётесь буквой диска — останетесь без данных)
5.4.1.4. Перемещение механизма доступа
Если выбрать из всех компонентов жёсткого диска один, который является его Ахиллесовой пятой, это будет механизм доступа. Объясняется это тем, что механизм доступа очень быстро и точно должен перемещаться на относительно большие расстояния. Кроме этого, механизм доступа перемещается неравномерно — он должен быстро ускоряться для перемещения к нужному цилиндру, а затем быстро останавливаться, чтобы не проскочить его. Мало того, механизм доступа должен быть крепким (чтобы противостоять силам, возникающим при быстром перемещении) и лёгким (чтобы его было легче ускорять/тормозить).
Одновременно достичь этих конфликтующих целей сложно и это объясняет тот факт, что на перемещение механизма доступа уходит больше времени, чем на работу других компонентов. Таким образом, в большей степени общая производительность жёсткого диска определяется временем перемещения механизма доступа, которое в среднем составляет порядка 5,5 миллисекунд.
5.4.1. Механические и электрические ограничения
Так как жёсткие диски являются электромеханическими устройствами, это накладывает на их скорость и производительность различные ограничения. Для выполнения каждого запроса ввода/вывода необходима совместная работа различных компонентов диска. Так как эти компоненты имеют свои характеристики производительности, общая производительность жёсткого диска определяется суммой производительности отдельных компонентов.
Однако электрические компоненты как минимум на порядок быстрее механических. Таким образом, наибольшее влияние на производительность диска оказывают механические компоненты.
Самый эффективный способ увеличить производительность жёсткого диска — сократить число механических действий, насколько это возможно.
Среднее время доступа типичного жёсткого диска приблизительно равно 8,5 миллисекунд. В следующих разделах рассматривается, откуда берётся это число, и показывается, как каждый компонент влияет на общую производительность жёсткого диска.
5.4.2.3. Ограниченность области чтения/записи
Хотя этот фактор влияет на производительность жёсткого диска не только в окружении со многими клиентами, но в таком окружении он обычно проявляется в большей степени. С точки зрения производительности важно, находятся ли запрашиваемые данные физически рядом с данными, запрошенными до этого, или далеко от них.
Почему это имеет значение, становится понятно, если вспомнить электромеханическое устройство жёсткого диска. Самым медленным компонентом любого жёсткого диска является механизм доступа. Таким образом, если для обращения к данным, указанным в поступающих запросах, перемещать механизм доступа не нужно, жёсткий диск сможет выполнить гораздо больше запросов, чем если запрашиваемые данные будут разбросаны по всему диску и для обращения к ним потребуется активно перемещать механизм доступа.
Это можно проиллюстрировать с помощью характеристик производительности жёсткого диска. В число этих характеристик обычно входит время перемещения на соседний цилиндр (когда механизм доступа перемещается на очень маленькое расстояние — только до следующего цилиндра), а время перемещения по всему диску (когда механизм доступа перемещается от самого первого цилиндра до самого последнего). Например, высокопроизводительный жёсткий диск имеет следующие характеристики:
Таблица 5-4. Время перемещения к соседнему цилиндру и по всему диску (в миллисекундах)
Читайте также: