Производительность дисковой подсистемы - фрагментация.

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

Онлайн-курс по устройству компьютерных сетей
На углубленном курсе "Архитектура современных компьютерных сетей" вы с нуля научитесь работать с Wireshark и «под микроскопом» изучите работу сетевых протоколов. На протяжении курса надо будет выполнить более пятидесяти лабораторных работ в Wireshark.

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

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

Начнем с теории, как мы уже разбирали, скорость доступа к различным частям жесткого диска различна. Наибольшая с внешней стороны и наименьшая с внутренней. Поэтому диск размечается таким образом, чтобы начало раздела было как можно ближе к началу диска (внешней части). Файловая система в свою очередь стремиться писать файлы именно в начало раздела, чтобы обеспечить максимальную производительность. Минимальной адресуемой областью диска на уровне ФС является кластер, стандартный размер которого 4 Кб.

Рассмотрим следующую схему:

Под номером 1 показана некая ситуация, когда начало диска полностью занято файлами, после которых следует непрерывный массив свободного места. Если мы захотим записать на диск новый файл (схема 2) то система разместит его последовательно в свободной области. Такая ситуация характерна при записи на чистый диск и фрагментация при этом минимальна или отсутствует.

Теперь несколько иная ситуация. Перед тем как записать новый файл, мы удалим несколько старых и на их месте появятся свободные области (схема 3). Если теперь попробовать записать новый файл, то система начнет заполнять им свободные области от начала раздела, несмотря на то, что в его конце есть достаточно места, чтобы записать файл в один прием (схема 4). Эта особенность работы NTFS делает ее расположенной к фрагментации. Причем чем меньше по размеру были удаленные файла и чем больше их было, тем сильнее будет фрагментация.

Вторая особенность NTFS состоит в том, что 12% емкости раздела резервируется для зоны MFT, где хранится главная файловая таблица. Запись в эту зону запрещена, однако когда на томе кончается свободное место, то размер этой зоны сокращается вдвое, затем еще раз вдвое и так до тех пор, пока не будет заполнено все свободное пространство. При появлении свободного места размер зоны MFT восстанавливается.

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

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

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

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

Чтобы не быть голословными разберем несколько практических примеров.

Случай первый. Раздел на RAID 10 из "черных" WD для размещения виртуальных машин стал показывать сниженную производительность, которая проявлялась в более долгом запуске и переводе виртуальных машин в состоянии паузы при повышенной дисковой активности в этот момент. Экспресс-тест показал следующие скоростные показатели:

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

Скорость линейного доступа сразу выросла до расчетных значений, но в нашем случае более важным оказался рост скорости случайного доступа (читай - количество IOPS), примерно 33% на чтение и 25% на запись. В тоже время падение количества IOPS гораздо менее заметно невооруженным глазом, чем падение линейной скорости. На системах с небольшой нагрузкой и случайным характером доступа снижение этого параметра до определенных пределов никак себя не проявляет (т.е. запаса по IOPS еще хватает), поэтому рост фрагментации до некоторого критического значения практически не влияет на производительность.

Случай второй. Терминальный сервер с размещенной на нем SQL-версией 1С:Предприятия 7.7, дисковый массив представляет из себя зеркало из двух "черных" WD, разбитый на три логических тома. Некоторое время назад на данном сервере произошла нештатная ситуация, что потребовало восстановления и, как следствие, записи на диски с последующим перемещением довольного большого количества данных.

Через некоторое время после этого стала проявляться крайне неудовлетворительная работа сервера на линейных дисковых операциях, вплоть до невозможности выполнить резервное копирование в течении разумного времени. Счетчики показывали крайне высокую нагрузку на диски: в среднем 350 IOPS, в пиках доходящую до 600, при длине очереди доходящей до 60. Тест производительности показал следующие результаты:

Если показатели по чтению еще можно с некоторой натяжкой назвать приемлемыми (на уровне 2,5" ноутбучных дисков), то с записью наблюдались серьезные проблемы. В первую очередь у нас возникли подозрения на физическую неисправность дисков, однако проверка никаких дефектов не выявила, стало ясно, что проблема находится не на уровне железа.

Примечательно, что к производительности 1С:Предприятия, в отличие от общей производительности сервера, вопросов в общем не возникало, что, учитывая характер нагрузки в SQL версии, как 80% чтение / 20% запись, вполне объяснимо с точки зрения полученных результатов.

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

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

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

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

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

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

Однако все обстоит несколько иначе. Ресурс современных SSD давно уже не вызывает каких-либо опасений по поводу "лишних" операций, даже если вы будете каждый день перезаписывать 100% ячеек SSD, ресурс диска будет исчерпан за 5-8 лет. Вы всерьез считаете что за это время ни разу не замените накопитель? К тому же статистика показывает, что основная масса отказов современных SSD никак не связана с ресурсом, на первом месте заводской брак и ошибки в прошивках.

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

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

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

Мы проиллюстрировали эту ситуацию на рисунке ниже:

С точки зрения файловой системы файлы расположены последовательно в начале диска (схема 1), на самом деле контроллер SSD размазал их "ровным слоем" по всей емкости диска (схема 2). Это делает процесс дефрагментации для SSD абсолютно бессмысленным, так как мы получим что-то сродни перетасовки колоды карт, данные как были, так и останутся равномерно распределены по всему диску.

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

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