Дефрагментация дисков в nas
Обновлено: 03.07.2024
Windows Server 2003 содержит средства обслуживания, которые вы можете использовать для обеспечения стабильной работы своего сервера. Регулярное техническое обслуживание является важной частью вашей работы, и те, кто забывает о необходимости выполнения задач технического обслуживания, обычно сожалеют об этом. В этой лекции описываются базовые средства обслуживания системы для версий Windows Server 2003.
Дефрагментация
Если вы открываете файл данных в какой-либо программе, вносите изменения в этот файл и сохраняете его, то в исходном месте хранения файла на диске может не хватить места для обновленного документа, если он стал больше. Операционная система разбивает документ, используя для части документа одно место на диске и для остальной части другое место . По мере увеличения размера файла его части могут сохраняться в нескольких местах на диске. Такой файл называют фрагментированным. При каждом открытии такого файла система должна выполнять поиск на диске, чтобы найти все его части. Процедура поиска замедляет вашу работу, поскольку для загрузки файла требуется несколько операций чтения диска.
Если вы удаляете файлы и папки, особенно группы файлов и папок, то образуются небольшие участки свободного места на диске, а при создании и сохранении новых файлов маловероятно, что эти файлы смогут размещаться в одной непрерывной области. В результате при каждом создании файла или папки либо сохранении измененного файла требуется все больше времени для записи на диск , поскольку система должна выполнить несколько операций записи в нескольких местах диска, чтобы сохранить новый объект . Диск становится фрагментированным. Windows Server 2003 содержит две встроенные программы дефрагментации дисков .
- Disk Defragmenter ( Дефрагментация диска ) в подменю System Tools (Служебные) меню Accessories (Стандартные). При выборе этого пункта меню открывается оснастка MMC dfrg. msc .
- Defrag .exe, которая запускается из командной строки.
Вы можете использовать любую из этих утилит для оптимизации своего диска путем дефрагментации файлов. Дефрагментатор выполняет сбор всех частей файла и записывает их на диск в одной непрерывной области. Программа создает место для каждого файла путем перемещения других файлов (которые тоже могут быть дефрагментированы) во временную область, пока не наступит их очередь дефрагментации .
Оснастка Disk Defragmenter
Для запуска графической версии встроенного дефрагментатора откройте подменю Accessories меню System Tools и выберите Disk Defragmenter . Вы должны иметь административные права, чтобы использовать эту оснастку.
Совет. Вы можете создать ярлык рабочего стола для Disk Defragmenter . Удерживая правую кнопку мыши, перетащите файл этой программы (%SystemRoot%\System32\dfrg. msc ) на рабочий стол и выберите в контекстном меню пункт Create Shortcut Here (Создать ярлык). Если вам нужно, то вы можете переместить этот ярлык в свою панель инструментов QuickLaunch (Быстрый запуск).Анализ диска
В окне Disk Defragmenter (рис. 8.1) выводится список локальных дисков вместе с информацией об установленной файловой системе, емкости диска и объеме свободного пространства на диске. Прежде чем запустить процедуру дефрагментации , нужно получить анализ диска, выполненный программой Disk Defragmenter . Дело в том, что дефрагментация – это интенсивная и длительная процедура, а проведенный анализ может показать, что у вас нет необходимости в проведении дефрагментации .
Рис. 8.1. В окне Disk Defragmenter отображаются все локальные диски
Для запуска процесса анализа можно использовать несколько способов:
- Щелкните правой кнопкой на диске и выберите в контекстном меню пункт Analyze .
- Выделите диск и щелкните на кнопке Analyze .
- Выделите диск и выберите пункт Analyze в меню Action (Действия).
Функция Analyze проверяет диск, и вы можете видеть ход этого процесса в панели Analysis Display . Области представляются соответствующим цветом:
- Синий – непрерывные файлы
- Красный – фрагментированные файлы
- Белый – свободное место
- Зеленый – системные файлы (которые нельзя перемещать).
Чтобы получить более подробную информацию о состоянии диска, щелкните на кнопке View Report (Просмотр отчета), и вы увидите, какие файлы и папки фрагментированы, а также количество фрагментированных сегментов для каждого из них ( рис. 8.2).
Примечание. Вы можете использовать кнопки окна Analysis Report (Отчет об анализе), чтобы напечатать отчет или сохранить его в текстовом файле , если это требуется по какой-либо причине.Выполните прокрутку списка файлов и папок, и если часто используемые файлы сильно фрагментированы, это может быть возможной причиной замедления работы вашей системы. Чем больше фрагментированных файлов у вас открыто, тем больше количество фрагментов, а это снижает производительность системы.
Просмотрев результаты отчета, вы можете решить, что нужна дефрагментация диска (даже если Disk Defragmenter не считает это необходимым). Процедуру Analyze следует запускать регулярно; периодичность запуска зависит от уровня активности вашего компьютера. Например, файл-серверы , которые используются большим числом пользователей, следует анализировать как минимум еженедельно.
Рис. 8.2. Вы можете видеть подробную информацию о текущем состоянии фрагментации
Дефрагментация диска
- Щелкните на кнопке Defragment .
- Выберите пункт Defragment в меню Action .
- Щелкните правой кнопкой на диске и выберите в контекстном меню пункт Defragment .
Ограничения Disk Defragmenter
Приложение Disk Defragmenter , включенное в Windows Server 2003, имеет некоторые серьезные ограничения. Это приложение получено от компании Executive Software , которая предоставила ограниченную версию ее полного продаваемого продукта. Имеются следующие ограничения.
- Вы не можете запускать Disk Defragmenter по заданному расписанию.
- Вы можете дефрагментировать только локальные тома; эту версию нельзя включать в дистанционные процедуры.
- Вы можете дефрагментировать единовременно только один том.
- Эту программу нельзя включать в скрипты.
Defrag.exe
Новым средством для Windows Server 2003 является программа defrag .exe, запускаемая из командной строки, и вы можете использовать эту программу вместо соответствующей оснастки. Эта исполняемая программа вызывает тот же код, что и оснастка (Executive Software Disk Defragmenter ).
Использование defrag .exe дает несколько преимуществ, и главным из них является то, что вы можете запускать эту программу по расписанию с помощью планировщика заданий Windows Server 2003 Task Scheduler , что невозможно при использовании описанной выше оснастки. Еще одним преимуществом, которое, возможно, является таковым только для приверженцев командной строки, является скорость и эффективность этой программы.
Результаты записи/чтения следующие:
Синолоджи показывает температуру дисков 32С, и ноль плохих секторов.
В какую сторону копать?
А еще посмотреть настройки сети, джумбо фрейм и не поплыл ли роутер.свитч, через который к нему все подключаются
Дефрагментация за эти три года хоть раз делалась? Если нет, сделайте и удивитесь результату.
А как дефрагментировать сетевой диск?! :))) Есть у меня NAS, стоит уже несколько лет.
2 диска собраны в страйп.
За это время, разумеется, ни разу не дефрагментировался.
Ибо программой "для диска компа" сетевой диск дефрагрментировать нельзя, а в утилитах NAS я такой функции не нашел.
А на NAS обычно этого и не нужно ext2/3 в общем-то в дефрагментации не нуждаются, ну только если диск заполнен под завязку. Так это просто решается через бэкап на внешний диск, форматирование основного, и копированием файлов обратно.
В общем, не думаю, что тут фрагментация виновата.
И лучше делать это не штатным дефрагментатором, а какой-нить специализированной прогой, которая позволяет выбрать несколько вариантов дефрагментации, в зависимости засранности диска от степени запущенности ситуации.
Я пользуюсь PerfectDisk - удобно, быстро, наглядно, куча режимов.
ты бы сначала поинтересовался, что там за фс так, для приличия.
2ТС: вынуть диск, подключить к компьютеру с линуксом, проверить смарт, протестировать скорость, прогнать fsck. Дальше по результатам.
Мда. Это инерция. Хоть и сам использую NMT Popcorn для которого ext3 - родная фс, всё равно форматирую диски в NTFS - мне так проще.
1почистить контакты сата
2 переткнуть шлейфы сата
3 заменить шлейфы
4 формат диска сделатьэ
5 проверить любой другой диск всунуть -если тоже самое то что то с коробкой
Спасибо. Буду копать в заданном направлении > 1почистить контакты сата
> 2 переткнуть шлейфы сата
> 3 заменить шлейфы
> 4 формат диска сделатьэ
> 5 проверить любой другой диск всунуть -если тоже самое то что то с коробкой
В этой статье попытаемся понять, как изменились процедуры обслуживания индексов для таблиц Microsoft SQL Server в современных условиях: при размещении файлов данных и журнала транзакций на SSD-дисках, многократном увеличении числа процессорных ядер и в условиях, когда оперативная память сервера стала измеряться Терабайтами.Действительно, мир стал другим. С тех пор как появились первые версии SQL Server, многое изменилось и многие методики, основанные на старых компьютерных ресурсах, работают уже не так эффективно, как прежде, когда без них невозможно было обойтись. Одной из таких методик, которая с давних пор воспринимается чуть ли не «серебряной пулей», а на деле превратилась в миф, является обязательная дефрагментация индексов, если в данные индекса достаточно часто вносятся изменения. Цель статьи развеять этот миф.
В своей документации, Майкрософт обращает наше внимание на то, что не стоит выполнять обслуживание индексов, не убедившись, что это принесёт пользу. Вот цитата:
«Чтобы избежать ненужного использования ресурсов, что может негативно влиять на рабочие нагрузки запросов, корпорация Майкрософт рекомендует не применять обслуживание индекса без предварительной оценки. Следует опытным путем оценить повышение производительности от обслуживания индексов для каждой рабочей нагрузки, используя рекомендуемую стратегию, и сопоставить его с затратами ресурсов и влиянием на рабочую нагрузку, которые потребуются для достижения этих преимуществ.»
В том же документе рассматриваются причины повышения производительности запросов после обслуживания индексов и делается замечание, что не всегда это связано с дефрагментацией, бывают и иные причины. Вот ещё одна цитата:
«Перестроение индекса дает еще одно важное преимущество: позволяет обновить статистику по ключевым столбцам индекса, сканируя все строки в индексе. Это эквивалентно операции UPDATE STATISTICS . WITH FULLSCAN, которая позволяет актуализировать статистику и иногда дает более точные данные, чем обычное обновление статистики по ограниченной выборке. При обновлении статистики заново компилируются все планы запросов, которые ее используют. Если прежний план запроса не был оптимальным из-за устаревшей статистики, недостаточного объема выборки для статистики или по любой другой причине, то после повторной компиляции многие планы дают лучшие результаты.»
Давайте попробуем определить, при каких условиях обслуживание индексов может принести больше вреда, чем пользы. Для начала вспомним, что такое дефрагментация и для чего она была нужна.
В документации дано следующее определение фрагментации индекса:
«В индексах сбалансированного дерева (rowstore) фрагментацией называют такое состояние, когда для некоторых страниц индекса логический порядок, основанный на значении ключа, не совпадает с физическим порядком страниц индексов». Отмечается также, что: «Если подсистема хранения имеет более высокую производительность последовательных операций ввода-вывода по сравнению с произвольными операциями ввода-вывода, то фрагментация индекса может привести к снижению производительности, ведь для чтения фрагментированных индексов требуется больше случайных операций ввода-вывода».
Это замечание важно, поскольку фактически является отсылкой к СХД на основе SSD, у которых все операции ввода вывода, как мы покажем дальше, являются случайными.
Есть ещё одно определение другого типа фрагментации, который в документации переведён на русский язык как «плотность страниц». С этим типом фрагментации связан важный факт, который влияет на актуальность статистик таблицы, не связанных с индексами. Вот, что написано в документации:
«Когда оптимизатор запросов компилирует план запроса, он учитывает стоимость операций ввода-вывода для чтения необходимых этому запросу данных. При низкой плотности страниц потребуется считывать больше страниц, а значит, и стоимость ввода-вывода будет выше. Это может повлиять на выбор плана запроса. Например, с течением времени плотность страниц уменьшается из-за разбиений, и оптимизатор может скомпилировать для того же запроса другой план с другой профилем потребления ресурсов и другой производительностью».
Пока что запомним это, поскольку подробнее коснёмся этого факта при анализе вызываемых дефрагментацией проблем с производительностью запросов.
В качестве резюме по типам фрагментации приведём тут выдержку из статьи: «Индексы. Теоретические основы»
Когда запись удаляется, в файле БД высвобождается место. Когда вставляется новая запись, это может привести к расщеплению страниц, что приводит к появлению пустого пространства на страницах данных. Когда данные обновляются, это может привести к изменению размера записи и к возникновению двух ранее упоминавшихся случаев. Все это приводит к фрагментации. В SQL Server рассматриваются два типа фрагментации: внутренняя и внешняя.1.Внутренняя подразумевает пустоты внутри страницы.2. Внешняя – непоследовательность связей страниц.Если страницы не полностью заполнены данными, это приводит к дополнительным операциям I/O и переиспользованию оперативной памяти. Помните, что страницы в оперативной памяти есть зеркальное отражение страниц на диске.В идеале страницы должны быть подлинкованы слева направо в порядке хранения данных. Вследствие расщепления страниц этот порядок может быть нарушен. Это приводит как к неполному заполнению страниц, так и к увеличению операций I/O вследствие непоследовательного положения цепочек страниц на диске – это вызывает дополнительные перемещения головок с цилиндра на цилиндр диска. А это одна из наиболее медленных дисковых операций.
В упомянутой только что статье были представлены методы обслуживания индексов, применяемые для SQL Server 2000. Обслуживание подразумевает две возможные операции: реорганизация индексов на уровне страниц для устранения внутренней фрагментации, или пересоздание индекса для устранения и внутренней и внешней фрагментации.
Давайте посмотрим, как с этим обстоит дело в современных версиях. Ещё в электронной документации к SQL Server 2005 было описано динамическое административное представление sys.dm_db_index_physical_stats. Тогда описание сопровождалось примерами использования, один из которых предлагал метод и правила автоматизации операций дефрагментации индексов в базе данных. Суть метода в том, что если значение avg_fragmentation_in_percent находится в диапазоне от 10 до 30, то в инструкции ALTER INDEX используется ключевое слово REORGANIZE, а если значение больше 30, то используется ключевое слово REBUILD.
В документе Разрешение фрагментации индекса путем реорганизации или перестроения индекса, предлагается использовать подобранные эмпирическим путём значения, взяв за основу данные из следующей таблицы:
avg_fragmentation_in_percent
Корректирующая_инструкция
ALTER INDEX REORGANIZE
ALTER INDEX REBUILD WITH (ONLINE = ON)
1 Эти значения дают примерное представление об определении точки, в которой необходимо переключаться между ALTER INDEX REORGANIZE и ALTER INDEX REBUILD. Однако фактические значения могут различаться в каждом конкретном случае. Важно определить наилучшее пороговое значение для используемой среды экспериментальным путем.
Эти рекомендации часто подвергались критике, поскольку пороги устанавливались исходя из очень пессимистичного сценария влияния фрагментации на производительность приложений, и большинство критиков считали их сильно заниженными. Вот одна из недавних статей на эту тему: Ваш скрипт, обслуживающий индексы, измеряет не то, что надо.
Существуют и другие предложения процентных порогов, один из которых был подробно изложен в книге: “Microsoft SQL Server 2005. Реализация и обслуживание. Учебный курс Microsoft“. Вот выдержка из этой книги, со страницы 368:
«Исполняйте инструкцию ALTER INDEX … REORGANIZE, чтобы выполнить дефрагментацию индекса, при соблюдении следующих пороговых значений: значение avg_page_space_used_in_percent в диапазоне от 60 до 75 или значение avg_fragmentation_in_percent в диапазоне от 10 до 15. Исполняйте инструкцию ALTER INDEX … REBUILD, чтобы выполнить дефрагментацию индекса, при соблюдении следующих пороговых значений: значение avg_page_space_used_in_percent меньше 60 или значение avg_fragmentation_in_percent больше 15».
В документации Майкрософт подчёркивается, что наибольший выигрыш дефрагментация даёт при операциях просмотра всего индекса или диапазона строк индекса или кучи. На операции поиска уровень фрагментации большого влияния не имеет. Это происходит потому, что просмотр выбирает данные не по дереву сбалансированного индекса, а по ссылкам на последовательность страниц, которые расположены непосредственно на самих страницах. На жёстких дисках время доступа к фрагментированным данным сильно зависит от времени позиционирования головок между цилиндрами. Операции с данными, расположенными на одном цилиндре, происходят быстро. Т.е. на время операций влияет Геометрия магнитного диска, которая схематично показана на рисунке из Википедии:
Всего этого механического «безобразия» больше нет на SSD дисках. Дефрагментация была полезна только для HDD c механическим перемещением головок над поверхностью диска. Расположение данных так, что для последовательного чтения не нужны перемещения готовки между «цилиндрами» позволяло повысить производительность последовательных операций чтения и записи. Надёжность и долговечность жёстких дисков тоже определяется возможностью перемещения головок. Пока это происходит штатно, диск будет работать, и возможности записи или чтения будут ограничены только старением или неисправностью привода.
В SSD дисках доступ к любым данным осуществляется за почти одинаковое время. Но в отличие от жёстких дисков, твердотельные диски изнашиваются, Для увеличения времени службы накопителя, ограниченного числом циклов перезаписи ячеек памяти, в SSD дисках используются алгоритмы рассеивания записи (для выравнивания износа), что превращает все последовательные операция чтения/записи в псевдослучайные. Схематично, это показано на рисунке ниже, взятого из стати Надежность SSD-накопителей: развенчиваем мифы и страхи пользователей.
С учётом этой особенности размещения данных на SSD можно отказаться от частого перестроения индексов, ограничившись реорганизацией или делать перестроение/реорганизацию вручную, при необходимости (например, для ускорения очистки фантомных строк или для сокращения времени пересчёта статистики). Прична банальна, SSD диск последовательную нагрузку всегда превращает в случайную. На логическом уровне индекс не будет фрагментирован, а на физическом фрагментация может быть абсолютной.
Для настольных компьютеров выполняемая не часто дефрагментация диска не приводит к заметному сокращению срока службы. Пользовательские файлы офисных приложений тоже фрагментируются. Те файлы, которые обычно пользователи размещают на дисках, не подвержены частой и интенсивной фрагментации. Если пользователь дефрагментирует файлы на диске раз в месяц – это не будет проблемой, хотя и не приведёт к ожидаемому повышению производительности, например, при создании моментального системного снимка. В отличие от этого, данные внутри файлов SQL Server могут подвергаться интенсивной фрагментации, и эта фрагментация может очень быстро достигать тех порогов, которые были обозначены выше, чтобы определить необходимость дефрагментации.
Для обслуживания индексов и статистики часто используют процедуру, автором которой является Ola Hallengren. В соответствии с выбранным набором параметров запуска, процедура устраняет внешнюю и внутреннею фрагментацию страниц. Следует отметить, что Майкрософт рекомендует для этих целей использовать процедуру AdaptiveIndexDefrag. Однако ни одна из этих процедур не умеет определять, располагаются ли файлы, в которых размещены индексы, на дисках SSD.
Те индексы, для которых был выбран REBUILD, обновляют статистику только для этих индексов. Цитата из документации Майкрософт, посвящённой статистике, глава Условия обновления статистики:
«Такие операции, как перестроение, дефрагментация и реорганизация индекса, не изменяют распределение данных, и поэтому после выполнения операций ALTER INDEX REBUILD, DBCC DBREINDEX, DBCC INDEXDEFRAG и ALTER INDEX REORGANIZE не нужно обновлять статистику. Но оптимизатор запросов обновляет статистику, когда выполняется перестройку индекса для таблицы или представления с помощью инструкции ALTER INDEX REBUILD или DBCC DBREINDEX. Такое обновление статистики является побочным эффектом повторного создания индекса. Оптимизатор запросов не обновляет статистику после операций DBCC INDEXDEFRAG и ALTER INDEX REORGANIZE.»
Однако, для оптимизатора запросов важным является ещё и стоимость операций ввода-вывода, которая зависит от плотности страниц. Если плотность страниц (внутренняя фрагментация) значительно изменится, а статистика для колонок останется неизменной, это может потенциально ввести оптимизатор в заблуждение и стать причиной выбора оптимизатором неоптимального плана запроса. Следует учитывать эти риски планируя обслуживание индексов.
Для размещённых на SSD дисках файлов данных, в подавляющем большинстве случаев дефрагментация не приведёт к ожидаемому повышению производительности дисковых операций, а только сократит срок службы SSD дисков и может привести к появлению неоптимальных планов запросов. Для SSD лучше полностью отказаться от перестроений и реорганизаций индексов на регулярной основе (это перестанет «убивать» диски). Такое решение кажется на первый взгляд весьма рискованным, влияние мифа о необходимости дефрагментации на нас очень велико. Если шок от этого предложения преодолеть трудно, попробуйте хотя бы не делать дефрагментацию каждый день и понаблюдайте за временем исполнения запросов. Когда поймёте, что время не меняется – продолжайте снижать частоту такого обслуживания. Отказавшись от ежедневной дефрагментации совсем, не забывайте обслуживать статистики индексов. Чем актуальнее статистики, тем проще оптимизатору выбирать хорошие планы для запросов.
Также увеличение числа страниц после изменений можно попробовать снизить за счёт сжатия данных индекса на уровне строк или страниц, как это описано тут: SQL SERVER – Rebuilding Index with Compression
Отказ от частой дефрагментации приведёт к следующим улучшениям:
Сокращение потребления ресурсов сервера на дефрагментацию
Дефрагментация портит статистику по колонкам (стоимость операций ввода-вывода), не входящим в ключ индекса. Без неё станет лучше статистика, а значит повысится качество планов запросов и сократиться время затронутых запросов.
Изменения распределения данных при дефрагментации передаются на реплики, поэтому отказ от дефрагментации сократит очереди на передачу и применение таких изменений.
Увеличится время жизни дисков SSD из-за сокращения числа циклов перезаписи ячеек хранения.
Теперь давайте перечислим те минусы, которые наиболее очевидны:
Время исполнения коротких транзакций не должно заметно измениться, но большие просмотры могут заметно удлиниться.
Увеличится время пересчёта статистик (стоит подобрать минимальный SAMPLE).
Размер файлов данных может заметно прибавить в весе.
До сих пор мы говорили об обслуживании индексов только в целях дефрагментации внешней и внутренней. Но это не единственное её предназначение. Пересоздание индексов можно использоваться для переноса данных в другую файловую группу, но эта операция обычно выполняется редко, необходимость её может ограничиваться единичными случаями. Более интересно перестроение индекса для удаления фантомных строк, как это указано в статье документации: Руководство по процессу очистки фантомных записей. В тех случаях, когда фоновый процесс очистки фантомных строк не успевает их чистить, и не удаётся эффективно использовать системную процедуру sp_clean_db_free_space, перестроение индекса оказывается наиболее быстрым и эффективным решением проблем с производительностью.
Резонный вопрос, почему в документации Майкрософт нет рекомендаций отказаться от дефрагментации индексов на SSD? Похоже, мы являемся свидетелями консервативного подхода, ориентированного прежде всего на небольшие базы данных, где пересоздание индексов не принесёт большого и даже заметного вреда. Однако, представленные выше в цитатах из документации оговорки должны обратить наше внимание на то, что к этому вопросу стоит подойти с разумением.
пятница, 8 июля 2011 г.
Имеет ли смысл дефрагментация диска в гостевой ОС?
Тема дефрагментации файловой системы периодически всплывает то на форуме, то просто в почте.
Так нужна ли дефрагментация в виртуальном мире, которая как известно, сильно помогает в мире физическом?
Начем с того, что такое фрагментация вообще и каково ее влияние на производительность. Итак, фрагментация - ситуация, когда блоки большого файла разбросаны по физическому диску в случайном порядке. Влияние фрагментации отлично видно на обычной домашней машине с одним жестким диском и большим количеством больших файлов (кино, фото и т.д.). В этом случае для чтения файла (например при копировании) головка диска не может осуществлять линейное последовательное чтение на максимальной скорости, а вынуждена метаться между блоками. Разумеется, все то время, что головка перемещается к нужному цилиндру и ждет начала блока с данными, чтения не происходит. Итог - снижение скорости чтения. Иногда кардинальное снижение, если файл оказался разбит на множество блоков малого размера.
Лечение - путем последовательных чтения/записи переместить по диску блоки файла таким образом, чтобы в максимальной степени сделать их последовательными и соотв. свести перемещания головки к минимуму.
Просто, очевидно и ведет к легко измеримому преимуществу. Но так ли это в виртуальном мире?
А вот здесь как раз зарыт бегемот.
Давайте представим себе среднего размера инфраструктуру с парой сотен виртуальных машин. Есть производительный массив с множеством дисков в RAID, машины генерируют нагрузку, жизнь движется.
Влияет ли как-то фрагментация файловых систем внутри ВМ на общую производительность. Парадокс, но практически нет.
1) Поскольку у нас есть массив из множества дисков, по которым равномерно размазаны данные, значительно снижается влияние перемещения головок - идет практически параллельное чтение с нескольких дисков, причем практически непредсказуемо.
2) Чем более интеллектуален дисковый массив, тем меньше само влияние самой медленной части дискового массива - дисков. Большой оперативный кэш, кэш второго уровня на флэш-дисках, многоуровненое хранение снижают влияние дисков вплоть до того, что до физических медленных магнитных дисков доходит иногда всего 10% операций чтения. Мощные процессоры, алгоритмы оптимизации и большой зеркалированный кэш с батарейкой позволяют не спешить записывать на диски поток команд как он идет, а делать это оптимальным образом в зависимости от уровня и прочих параметров RAID, в минимальное количество операций.
3) Одновременная нагрузка с десятков и даже сотен виртуальных машин привод к тому, что только внутри ВМ дисковые операции выглядят как линейное чтение. До дискового массива чтение/запись доходит уже как практически случайная последовательность команд. От того, что файл внутри из одной ВМ расположен непоследовательно, практически ничего не меняется.
Итого: если ВМ расположены на малоинтеллектуальном массиве начального уровня (или просто на внутреннем RAID сервера) на малом количестве физ. дисков (шпинделей), и их мало, то дефрагментация может иметь смысл и снизить нагрузку на дисковую систему / повысить общую производительность.
Однако с ростом размеров инфраструктуры и повышении класса дисковой системы фрагментация перестает играть сколько нибудь значимую роль. Зато дефрагментация становится не спасением, а самым настоящим злом. Вспомним, что собой представяет процесс дефрагментации - множество операций чтения / записи (1 к 1) в объеме, доходящим до 100% данных на диске.
1) Существует такое понятие, как RAID penalty - штраф к производительности в силу того, что используется RAID. Кратко, при использовании RAID 1 (1+0) каждая операция записи со стороны ВМ превращается в 2, когда доходит до дисков. Для RAID 5 - 4, RAID 6 - в 6! Итого, сам процесс дефрагментации очень сильно просаживает производительность. В случае же с флэш-дисками, еще и сильно сокращает срок службы.
2) Снапшоты. Вы же их используете? Дефрагментация вырастит снапшот до размеров базового диска легко и непринужденно. А кстати, вы не забыли, что снапшот сам по себе дает очень большой штраф к производительности дисковой системы? Который надо умножить на RAID penalty. А потом этот немеряно выросший как на стероидах снапшот надо коммитить. Что снова дает нам много-много записи, которую так не любит RAID.
3) Вы говорите не используете снапшоты? А как же VMware-level резервное копирование ВМ? Оно реализовано через снапшоты, и существуют совсем ненулевые шансы того, что встретятся вместе задания бэкапа и дефрагментации.
4) И кстати, вы используете для бэкапа Changed Block Tracking? забудьте о нем, дефрагментация вырастит статистику измененных блоков (хранится в ctk файле) вплоть до объема диска, и вместо быстрого инкрементального бэкапа вы получите медленный полный.
5) Тонкие диски (thin provisioning). Скажите им тоже "до свидания", при дефрагментации тонкие диски начнут очень быстро превращаться в обычные толстые, и все их преимущества будут сведены на нет.
Читайте также: