Аннотация
В статье исследуется зависимость производительности HDD от степени фрагментации данных. Показано, что падение производительности носит нелинейный характер и имеет критические точки, при которых эффективность работы диска резко снижается. Рассмотрены физические механизмы, обуславливающие данную зависимость, приведены расчетные данные и математическая модель.
Что такое фрагментация?
Фрагментация — это состояние, при котором файлы физически располагаются на разных участках диска, а не непрерывно друг за другом. Из-за этого магнитная головка вынуждена совершать лишние движения, тратя значительное время на поиск нужных участков. По мере накопления фрагментов файлов снижается общая скорость работы накопителя, ухудшается отклик системы и увеличивается износ самого устройства.
Введение процедуры дефрагментации способно кардинально изменить ситуацию. Суть дефрагментации заключается в объединении отдельных фрагментов файлов в единую область на диске, сокращая путь движения головок и уменьшая среднее время доступа к данным. Этот процесс оказывает непосредственное влияние на повышение общей производительности системы, снижение нагрузки на аппаратуру и продление срока службы HDD.Далее мы подробно изучим механизм воздействия фрагментации и дефрагментации на показатели скорости работы жесткого диска, используя конкретные расчеты и наглядные примеры.
Характеристики HDD
Основные характеристики HDD:
-Объем, Гб;
-Линейная скорость чтения/записи(скорость считывания/записи после позиционирования), Mb/s ;
-Количество оборотов диска в минуту, rpm;
-Время перехода track to track, ms.
Возьмем для моделирования HDD со следующими характеристиками:
Зададимся условным тестируемым файлом, который будет читаться с HDD. Размер файла равен 1 МБ.
Построим модель работы HDD при чтении файла.
1) Файл состоит из кластеров. Количество кластеров в файле:
2) Время чтения кластера.
3) Время позиционирования.
Теперь составим формулу по которой рассчитывается время чтения файла в зависимости от фрагментации:
То есть, время чтения файла зависит от количества кластеров умноженных на время чтения одного кластера сложенного со временем затрачиваемым на позиционирование на кластере, которое зависит от степени фрагментации.
Посчитаем время чтения файла для разных степеней фрагментации и размера кластера:
Построим графики относительной скорости HDD в зависимости от степени фрагментации:
Рассчитаем таблицу как меняется скорость HDD в зависимости от размера кластера и фрагментации:
Как видно на маленьких размерах кластера быстродействие даже при незначительной фрагментации падает значительно. Например, при размере кластера 512 байт и фрагментации 5% быстродействие уже падает до ~1% относительно скорости линейного чтения.
На кластерах больших размеров быстродействие падает значительно медленнее, что объясняется тем, что диск затрачивает намного меньшее времени на операции позиционирования.
Также, по графику видно, что зависимость скорости HDD от фрагментации является нелинейной и быстродействие значительно спадает уже после нескольких десятков процентов фрагментации данных. Поэтому на скорость работы HDD значительно влияет не только степень фрагментированости данных на диске, но и размер кластера. Из чего также можно сделать вывод, что кэши не больших размеров не могут сильно ускорить работу HDD.
Для того чтобы учесть попадания в кеш в формуле (4) нужно умножить количество кластеров на коэффициент попадания в кеш, тогда будет известно реальное количество чтений кластеров:
Размер кеша, например, если диск HDD работает с базой данных размером 1Гб, то для того чтобы обеспечить 10% попадания в кеш: нужен кеш размером 100Мб. Но эта оценка не учитывает повторных попаданий, если учитывать повторные попадания в кеш, то коэффициент попаданий будет больше.
Чтобы получить большее быстродействие (ориентируясь на расчеты и Рисунок 3) нужно 0%-10% процентов фрагментации. Из чего можно сделать вывод, чтобы получать высокую скорость работы HDD нужно дефрагментировать данные и использовать большой кеш, тогда быстродействие будет высоким.
Выводы
Производительность HDD падает нелинейно с ростом фрагментации данных.
Кеши не большого объема не сильно повлияют на рост скорости.
Для повышения эффективности нужно дефрагментировать не только сами файлы, но и также файлы относительно друг друга.
Желательно использовать кластеры большого размера при условии высокой утилизации данных при записи и чтении.
Комментарии (18)
aik
11.01.2026 07:28Хуже всего, когда большие файлы на много мелких кусочков разбиты. У нас это проявлялось на базах почтовиков в десятки гигабайт. Дефрагментация заметно помогала работу ускорить.
Но после того, как все диски в юзерских компах заменили на ссд, вопрос закрылся. Ибо основное преимущество ссд перед винтами - это не скорости чтения/записи, а нулевое (ну, маленькое и везде одинаковое) время доступа. Пока диск не забит на 90%.
Впрочем, черепичные винты...
lex899
11.01.2026 07:28Ибо основное преимущество ссд перед винтами - это не скорости чтения/записи, а нулевое (ну, маленькое и везде одинаковое) время доступа.
SSD имеют разброс времени доступа в один порядок, видел это на графиках в разных статьях, специально поигрался с тестами на случай если информация устарела - для моего nvme от samsung примерно 3% запросов дают провал до 20ms, остальные операции укладываются в 2ms.
Для одиночного ssd этим можно пренебречь, но собрав полку из 24 дисков - вы получите среднее время доступа ~11ms вместо 2ms при таких вводных.
GidraVydra
11.01.2026 07:28примерно 3% запросов дают провал до 20ms, остальные операции укладываются в 2ms. Для одиночного ssd этим можно пренебречь, но собрав полку из 24 дисков - вы получите среднее время доступа ~11ms
Интересно вы усредняете.
HardWrMan
11.01.2026 07:28Скорость некоторых схем RAID равняется самому медленному диску в схеме.
lex899
11.01.2026 07:28Скорость некоторых схем RAID равняется самому медленному диску в схеме.
Из базовых в таком размере знаю только raid6 (бывает raid0, но под специфические задачи). Есть нюансы с размером кластера/страйпа/логикой контроллера, но вцелом на случайном чтении можно считать по минимальному, на любой записи или линейном чтении выйдет по самому медленному.
Условный raid60 это 2х12 дисков, уже ~7.5ms. При этом по мере загрузки/нагрузки/возраста цифры могут весьма неожиданно вырасти. Буквально в праздники наблюдал падение скорости линейного чтения ssd raid5 на 2 порядка.
GidraVydra
11.01.2026 07:28Это не так работает даже для скорости, а уж для времени доступа и подавно.
VT100
11.01.2026 07:28Не указано, что (4) даёт оценку снизу. Как минимум - потому, что не все файлы фрагментированы. Далее - в ход могут вступить кэширования. Начиная с того, что в самом диске может оказаться в кэше вся дорожка.
Классика Хабра
eevg Автор
11.01.2026 07:28Дописал про кеш. По сути кеш в формуле (4) дает сокращение количества секторов для чтения.
DGG
11.01.2026 07:28Для меня в вопросах дефрагментации самым неочевидным была необходимость время от времени делать дефрагментацию SSD.
Да, там внутри SSD свои таблицы аллокации и записанное подряд может физически лежать по разным местам чипов памяти и наоборот, но сильная фрагментация на уровне MFT делает своё дело и со временем начинает вносить большие накладные расходы, видимо.
Попался мне тут компьютер родственницы, собранный ей частным мастером, который полностью отключил в Win10 периодический запуск встроенного дефрагментатора и поставил сторонний, даже с запуском по расписанию. И всё бы ничего, но лет 4-5 назад на него закончилась лицензия.
Так до дефрагментации оно ворочалось прям как будто на HDD стоит. Представляю в какую раздутую кашу там превратился MFT.
muhamuha
eevg Автор
Да в Досе это помогало ускорить диск. В многозадачных операционных системах сложнее. Там выгоднее запрашиваемые данные располагать на одной дорожке и читать дорожку целиком тем более объём современных кешей позволяет. Для HDD время чтения одной дорожки сравнимо с временем перемещения дорожки к дорожке.
muhamuha
по-моему, одиночные HDD остались в домашних системах, а в более-менее серьезном проде - RAID. И там уже с дефрагментацией всё иначе. Не говоря уже о системах, отличных от FAT/NTFS. Статья хорошая, устарела лет на 20, а так да, тёплая, ламповая :)
HardWrMan
Не только в DOSе. Вот этот парень имел наилучшую стратегию и алгоритм для упорядочивания:
Но он оказался заложником Win9x, где имел свой драйвер-прослойку для дисков. Когда майки всех вытолкнули на NT (с приходом XP), то я читал что для Norton Speed Disk M$ не сертифицировала этот драйвер и вынуждала использовать встроенный в систему API дефрагментации, это для которого сделали вот такой GUI сами M$:
Тут ещё скорее всего наложился переход с FAT на NTFS и всё такое.
Как по мне, для всех видов FAT для Win9x лучше, чем Norton Speed Disk 99/2000/2001 нет. Он быстр, у него отличный алгоритм сортировки, который заметно сокращает количество дисковых операций для переноса и упорядочивания данных. Да и сам процесс дефрагментации крайне быстр. А вот под NT лично я перепробовал много разных ныне доступных программ и только PerfectDisk смог упорядочить не только файлы, но и подкачку, гибернацию и даже MFT$, что так же влияет на скорость работы магнитного диска. Ну и стратегии у него хорошие, правда с оптимальностью сортировки не очень, но поддерживать дефрагментацию можно относительно быстро, хотя первичная может затянуться на много часов.
Vitimbo
Своими скриншотами отправили меня куда-то в начало века, спасибо :)
vis_inet
А что можете сказать про Defraggler ?
HardWrMan
К сожалению, она не отложилась у меня в голове. Сейчас посмотрел скриншоты - никаких особых воспоминаний. Либо она не попалась мне в своё время, либо не оставила о себе каких-либо значимых впечатлений. Попробую её на днях и поделюсь своим мнением если не забуду.
PS Есть целый класс дефрагментаторов для NT, которые суть оболочка для встроенного API. А у него, насколько я понял когда читал про него, есть жёсткие ограничения во всём: в стратегии, в скорости и даже в размере блока. А ещё, там есть какие-то ограничения с MFT$ и директориями. Norton Speed Disk отлично сортировал и оптимизировал директории и LFN в них, сжимая и упорядочивая сам файл директории. PerfectDisk точно это делает с NTFS, но в Boot Time режиме (на самом деле это просто однозадачный режим до загрузки оболочки, на подобии того, что использует chkdsk при проверке системного тома). Если Defragger не умеет в это то он по сути бесполезен и является просто оболочкой системного API.