Comments 28
Дефрагментация была полезна только для HDD c механическим перемещением головок над поверхностью диска.
Для размещённых на SSD дисках файлов данных, в подавляющем большинстве случаев дефрагментация не приведёт к ожидаемому повышению производительности дисковых операций, а только сократит срок службы SSD дисков и может привести к появлению неоптимальных планов запросов.
Хм, а вот немцы из oo-software считают иначе.
Более того, если обратите внимание, сама Microsoft является золотым партнером этой компании и её продукта(ов).
Скажите пожалуйста, что думаете по этому поводу?
какая-то у вас сплошная теория... где с измерениями? Логическая дефрагментация никак не связана с физической, более того - это разные явления. Да и пассаж про SSD и размещение данных, по сравнению с жеским диском, выглядит странно - диски тоже все используют в RAID и контроллер массива сам решает что и как ему делать.
Статья и так длинная получилась,
я бы не сказал
а что будет, если я ещё и графики сюда выложу со всеми возможными типами нагрузки и конфигурациями дисковой подсистемы.
ну так выложите, будет гораздо интереснее
Лично мне, статью с цифрами тестов, но без лишней воды (которая есть сейчас), было бы интереснее прочитать. А так, зашел на интересный заголовок, а ничего в замен не получил.
Эту же информацию я получил несколько лет назад, из статьи Брента Озара. Он рекомендовал поменять трешхолды в дефолтных значениях скрипта Ola.
https://www.brentozar.com/archive/2014/12/tweaking-defaults-ola-hallengrens-maintenance-scripts/
Сокращение потребления ресурсов сервера на дефрагментацию
у меня как-то ms sql ассоциируется с 1с )
в случае с 1с обычно вполне есть технологическое окно для перестройки индексов
Увеличится время жизни дисков SSD из-за сокращения числа циклов перезаписи ячеек хранения.
ну… сейчас посмотрел: p4510, аптайм 2.5 года, еженощные перестроения индексов в терабайтной базе.
по мнению накопителя израсходованный ресурс 7%. при этом накопитель совсем не рекордсмен по ресурсу, ЕМНИП 1 DWPD.
У меня сейчас на базах 1С дефрагментация раз в месяц — хотя большие проценты каждый день фрагментируются.
у меня работает известный скрипт от ola, каждую ночь переиндексация таблиц с более, чем 5% изменений, раз в неделю — всех. ну и обновление статистики, разумеется.
одной из мотиваций сделать так было то, что полная переиндексация при высоком maxdop идёт очень быстро.
именно дефрагментации (INDEX_REORGANIZE) нет, согласен, что на ssd она не особо полезна.
Размер файлов данных может заметно прибавить в весе.
это же не только размер файлов сам по себе, это более «рыхлые» индексы, соответственно больше дискового io, меньше полезных данных помещается в кэше и т.п.
Дефрагментация портит статистику по колонкам (стоимость операций ввода-вывода), не входящим в ключ индекса. Без неё станет лучше статистика, а значит повысится качество планов запросов и сократиться время затронутых запросов.
про это можно подробнее, где почитать?
Это замечание важно, поскольку фактически является отсылкой к СХД на основе SSD, у которых все операции ввода вывода, как мы покажем дальше, являются случайными.
а вы точно это показали? )
разница между случайным и последовательным доступом на ssd, конечно, не такая фатальная, как на hdd, но всё равно…
fio --name=randread --rw=randread --bs=8k --runtime=10 --time_based=1 --filename=/dev/nvme0n1p1 --iodepth=1 --randrepeat=0 --direct=1
fio --name=read --rw=read --bs=8k --runtime=10 --time_based=1 --filename=/dev/nvme0n1p1 --iodepth=1 --randrepeat=0 --direct=1 READ: bw=114MiB/s (120MB/s), 114MiB/s-114MiB/s (120MB/s-120MB/s), io=1140MiB (1196MB), run=10001-10001msec READ: bw=643MiB/s (674MB/s), 643MiB/s-643MiB/s (674MB/s-674MB/s), io=6430MiB (6743MB), run=10001-10001msecразница в 5-6 раз
Но я имел ввиду банальную вещ, что последовательное чтение с SSD диска будет собирать случайно разбросанные по ячейчас блоки (которые размером могут и не совпадать с размером страницы MSSQL)
да.
но практика показывает, что внутри ssd есть оптимизации, направленные на ускорение последовательного чтения, и случайное чтение если и может приблизиться по скорости к последовательному, то только при увеличении глубины очереди.
Также Вы упустили из вида упреждающее чтение (readahead), за счёт которого можно получить значительный прирост скорости на дефрагментированных индексах как на локальных ссд, так и на сетевых дисковых массивах особенно.
Рекомендую посмотреть Березнёва Александра. Там наглядно приводятся цифры и факты.
Увы, упреждающее чтение одинаково влияет на фрагментированные и не фрагментированные индексы, уточните, что именно было упущено?
Упреждающее чтение позволяет считывать последовательные экстенты индексов с диска одним блоком до 512 Кб. Как об этом написано в документации. По факту, видимо, более длинными. Но это работает только в том случае, если индекс дефрагментирован.
Если оперативки достаточно, эффекта не будет почти никакого.
Вот, кстати, зря, что не досмотрели, за14 минутой начинается самая мякотка - влияние скорости выполнения запросов по фрагментированым и дефрагментированным индексам, которые расположены в буферном кеше. В том числе и с уменьшением fillfactor дефрагментированного индекса, для получения сравнимых объёмов.
К видео же особых претензий нет, кроме того, что как-то незаметно сравнивать стали фрагментированную таблицу и таблицу с филфактором не по умолчанию
так это логично как раз же, нет?
я до просмотра этого видео как раз считал, что на ssd основным фактором снижения производительности в случае фрагментации будет «распухание» индексов (фактически мы увеличиваем весь дисковый io, плюс уменьшаем буферный пул, что по сути тоже ведёт к увеличению дискового io, плюс несколько увеличиваем нагрузку на процессор — все эти неиспользуемые области в страницах индекса будут попадать в процессорный кэш, вымывая оттуда полезные данные).
честно говоря, мне не очень понятно, откуда взялась эта разница в видео. ИМХО тема требует дальнейшего изучения.
увидел ваш комментарий на sql.ru:
И что делать, если изменний и дефрагментаций получается так много, что SSD диски энтерпрайз-класса заканчиваются за год-два?
если я правильно понимаю доку, то переиндексация порождает запись в размере двухкратного размера индекса (причём половина записи может быть перенаправлена в tempdb).
с учётом того, что, всё-таки, перестраивать приходится далеко не все индексы, не очень понятно, как у вас получается «стачивать» ssd за год. берёте диски с dwpd=0.3?
Обслуживание подразумевает две возможные операции: реорганизация индексов на уровне страниц для устранения внутренней фрагментации, или пересоздание индекса для устранения и внутренней и внешней фрагментации.
Почему только внутреннюю? Ведь реорганизация устраняет и внешнюю фрагментацию.
P.S. есть ли где-то описание имплементации алгоритма реорганизации?
Отказ от ежедневной дефрагментации