Насколько в действительности фрагментация может снизить производительность HDD и как это измерить

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

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

Дефрагментация упорядочивает структуру данных, минимизирует перемещения головки и сокращает время доступа к информации. Но задумывались ли вы, насколько на самом деле дефрагментация HDD может повысить производительность накопителя и можно ли рассчитать эту зависимость математически? На первый взгляд это может показаться непростым, но на практике вполне реально.

Итак, начнем.

Сначала определим переменные, в которые будем подставлять реальные данные.

Переменная	Что означает на практике
Sfile	Размер файла в KB, MB или GB, который будет читаться с диска
Scl	Размер кластера — минимальной ячейки на диске, для определения размера используйте команду fsutil fsinfo ntfsinfo D: (пункт “Байтов на кластер”)
Vlin	Скорость чтения данных, можно замерить CrystalDiskMark или аналогичной программой
Tpos (смотрите подробнее ниже)	Время, которое тратит головка, чтобы перелететь с одного фрагмента файла на другой
Frag	Текущая фрагментация диска в процентах, можно посмотреть в свойствах HDD на вкладке «Сервис». Для математических расчетов проценты нужно перевести в десятичную дробь: например, 15% фрагментации = 0.15
Kcache	Коэффициент кэша, процент данных, которые диск уже запомнил и не лезет за ними на пластину. Изменчивый параметр, зависит от разных факторов, в среднем составляет 0.1 для файлов на пользовательском разделе и 0.5 – для файлов на системном

Tpos рассчитывается по формуле Tpos=Seek Time+Latency, где Seek Time — время перемещения головки на нужную дорожку, а Latency — время ожидания поворота диска нужным сектором под нее. Ищите эти константы в технических характеристиках HDD на сайте производителя.

Для дисков со скоростью вращения 5400 RPM среднее значение Tpos составляет примерно 17.55 мс, для 7200 RPM — 13.17 мс и для 10000 RPM — 7 мс.

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

Подготавливаем формулы расчетов

Теперь соберем эти переменные в логическую цепочку.

Сначала определим количество кластеров, которые занимает файл (Ncl).

Ncl = Sfile / Scl

Определим количество фактических разрывов (Jumps) – прыжков считывающей головки:

Jumps = Ncl * Frag

Рассчитаем время чистого чтения (Tpure), как если бы фрагменты файла лежали бы рядом:

Tpure = Sfile / Vlin

Рассчитаем полное время чтения файла с учетом перемещений считывающей головки и коофициента кэша:

Ttotal = (Tpure + (Jumps * Tpos)) * (1 − Kcache)

Наконец, получаем итоговую реальную скорость (Vreal) чтения фрагментированного файла:

Vreal = Sfile / Ttotal

Теперь осталось только подставить фактические значения в формулы.

Возьмем для примера диск 7200 RPM, линейной скоростью чтения 150 Мб/c (Tpos 0.01317 сек), файл 1 Мб, размер кластера 4 Кб и уровень фрагментации 20% (0.2). Обращаем внимание, что все данные должны быть в одной системе координат: размер файла и кластера только в Мб, скорость (Vlin) в МБ/с, время (Tpos) только в секундах.

Ncl = 1 / 0.00390625 = 256

Jumps = 256 * 0.2 = 51.2

Tpure = 1 / 150 ≈ 0.00667 сек

Ttotal = (0.00667 + (51.2 * 0.01317)) * (1−0.1) ≈ 0.61287 сек

Vreal = 1 / 0.61287 ≈ 1.63 МБ/с

Как можно видеть из примера выше, фрагментация файла на 20% может замедлить скорость его чтения почти в сто раз.

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

Размер кластера (Scl)	Прыжки (Jumps)	Время чтения (Ttotal)	Реал. скорость (Vreal)
512 Б	410	~4.85 сек	0.20 МБ/с
2 КБ	102	~1.22 сек	0.82 МБ/с
4 КБ (Стандарт)	51	~0.61 сек	1.63 МБ/с
16 КБ	13	~0.16 сек	6.25 МБ/с
64 КБ	3	~0.04 сек	25.0 МБ/с

Однако многие наши читатели могут возразить: «Почему тогда мы не всегда ощущаем падение скорости в 100 раз?»

Все дело в том, что для демонстрации мы взяли «идеальный» вариант, тогда как в реальности ситуация немного иная.

Во-первых, операционная система использует функцию Pre-fetching, загружая определенные файлы в ОЗУ еще до того, как пользователь к ним обратится. К этому добавляется тот факт, что часть системных файлов постоянно находится в оперативной памяти.

Во-вторых, замедление для маленьких файлов, даже в сто раз, практически незаметно — разница между 0,001 сек и 0,1 сек для человека почти неощутима.

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

Но это нисколько не отменяет главный вывод: фрагментация, особенно при малом размере кластера, может существенно снизить производительность HDD.

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