Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Microsoft SQL Server Новый топик    Ответить
 Есть ли смысл делать дефрагментацию индексов, расположенных на массиве из SSD дисков?  [new]
Prolog
Member

Откуда: Москва
Сообщений: 2791
Есть ли смысл делать дефрагментацию индексов, расположенных на массиве из SSD дисков?
27 сен 17, 09:40    [20825767]     Ответить | Цитировать Сообщить модератору
 Re: Есть ли смысл делать дефрагментацию индексов, расположенных на массиве из SSD дисков?  [new]
TaPaK
Member

Откуда: Kiev
Сообщений: 6794
Prolog,
простой ответ да, но вопрос что вас беспокоит :)
27 сен 17, 09:52    [20825803]     Ответить | Цитировать Сообщить модератору
 Re: Есть ли смысл делать дефрагментацию индексов, расположенных на массиве из SSD дисков?  [new]
aleksrov
Member

Откуда:
Сообщений: 948
Prolog,

https://www.sqlskills.com/blogs/jonathan/does-index-fragmentation-matter-with-ssds/
27 сен 17, 09:56    [20825810]     Ответить | Цитировать Сообщить модератору
 Re: Есть ли смысл делать дефрагментацию индексов, расположенных на массиве из SSD дисков?  [new]
Prolog
Member

Откуда: Москва
Сообщений: 2791
aleksrov, спасибо. Статью обязательно почитаю.

TaPaK, я так понимаю. Дефрагментация индексов приводит к тому, данные на диске, относящиеся к одному индексу, располагаются последовательно, как бы "одним куском". Поэтому при их считывании с HDD механическая головка не будет бегать с дорожки на дорожку, с края диска на край, а последовательно считывать одну дорожку и переходить на следующую. Т.е. для HDD мы, в первую очередь, экономим время на времени движения головки. В SSD нет механического перемещения, поэтому, как мне кажется, дефрагментация индексов уже не так принципиальна.
27 сен 17, 12:13    [20826373]     Ответить | Цитировать Сообщить модератору
 Re: Есть ли смысл делать дефрагментацию индексов, расположенных на массиве из SSD дисков?  [new]
TaPaK
Member

Откуда: Kiev
Сообщений: 6794
Prolog,

приведённу ссылку лень открывать? кроме чтения есть ещё место(для SSD это $) и количество операций.
27 сен 17, 12:17    [20826386]     Ответить | Цитировать Сообщить модератору
 Re: Есть ли смысл делать дефрагментацию индексов, расположенных на массиве из SSD дисков?  [new]
invm
Member

Откуда: Москва
Сообщений: 9128
Prolog
В SSD нет механического перемещения, поэтому, как мне кажется, дефрагментация индексов уже не так принципиальна.
Фрагментация бывает логическая (внешняя) и физическая (внутренняя).
Вы, в своих рассуждениях, не учитываете физическую, которая всегда приводит к увеличению логических чтений при сканировании.
27 сен 17, 12:56    [20826478]     Ответить | Цитировать Сообщить модератору
 Re: Есть ли смысл делать дефрагментацию индексов, расположенных на массиве из SSD дисков?  [new]
Prolog
Member

Откуда: Москва
Сообщений: 2791
Таблица - лог событий. Индекс с fill_factor = 100. События пишутся с последовательно возрастающим id и datetime. Изменения в таблице (update, delete) не производится.
27 сен 17, 13:03    [20826491]     Ответить | Цитировать Сообщить модератору
 Re: Есть ли смысл делать дефрагментацию индексов, расположенных на массиве из SSD дисков?  [new]
o-o
Guest
Prolog
Таблица - лог событий. Индекс с fill_factor = 100. События пишутся с последовательно возрастающим id и datetime. Изменения в таблице (update, delete) не производится.

тут более уместен другой вопрос:
есть ли смысл делать дефрагментацию индексов, если фрагментации практически нет?
а то вот еще хороший вопрос: надо ли дефрагментировать таблицу сразу после truncate? (Козлов-33)
27 сен 17, 13:13    [20826520]     Ответить | Цитировать Сообщить модератору
 Re: Есть ли смысл делать дефрагментацию индексов, расположенных на массиве из SSD дисков?  [new]
TaPaK
Member

Откуда: Kiev
Сообщений: 6794
Prolog,

автор
Есть ли смысл делать дефрагментацию индексов, расположенных на массиве из SSD дисков?

автор
Таблица - лог событий. Индекс с fill_factor = 100. События пишутся с последовательно возрастающим id и datetime. Изменения в таблице (update, delete) не производится.

у матросов больше нет вопросов...
27 сен 17, 13:18    [20826537]     Ответить | Цитировать Сообщить модератору
 Re: Есть ли смысл делать дефрагментацию индексов, расположенных на массиве из SSD дисков?  [new]
архивариус
Member

Откуда:
Сообщений: 149
aleksrov
Prolog,

https://www.sqlskills.com/blogs/jonathan/does-index-fragmentation-matter-with-ssds/


для информации тоже самое что по ссылке но вместо SSD база на HDD, для сравнения
'async_io_completed', 'GuidHighFragmentation', 149,
'async_io_requested', 'GuidHighFragmentation', 149,
'file_read', 'GuidHighFragmentation', 149,
'file_read_completed', 'GuidHighFragmentation', 149,
'physical_page_read', 'GuidHighFragmentation', 771,
'async_io_completed', 'GuidLowFragmentation', 3,
'async_io_requested', 'GuidLowFragmentation', 3,
'file_read', 'GuidLowFragmentation', 3,
'file_read_completed', 'GuidLowFragmentation', 3,
'physical_page_read', 'GuidLowFragmentation', 451
27 сен 17, 13:19    [20826538]     Ответить | Цитировать Сообщить модератору
 Re: Есть ли смысл делать дефрагментацию индексов, расположенных на массиве из SSD дисков?  [new]
архивариус
Member

Откуда:
Сообщений: 149
архивариус,
QueryTable, read_size_kb, read_size_pages, occurences
'GuidHighFragmentation', 104, 13, 1,
'GuidHighFragmentation', 88, 11, 1,
'GuidHighFragmentation', 80, 10, 4,
'GuidHighFragmentation', 72, 9, 8,
'GuidHighFragmentation', 64, 8, 27,
'GuidHighFragmentation', 56, 7, 12,
'GuidHighFragmentation', 48, 6, 12,
'GuidHighFragmentation', 40, 5, 13,
'GuidHighFragmentation', 32, 4, 18,
'GuidHighFragmentation', 24, 3, 23,
'GuidHighFragmentation', 16, 2, 27,
'GuidHighFragmentation', 8, 1, 3,
'GuidLowFragmentation', 3288, 411, 1,
'GuidLowFragmentation', 256, 32, 1,
'GuidLowFragmentation', 64, 8, 1
27 сен 17, 13:26    [20826562]     Ответить | Цитировать Сообщить модератору
 Re: Есть ли смысл делать дефрагментацию индексов, расположенных на массиве из SSD дисков?  [new]
Александр Гладченко
Member

Откуда:
Сообщений: 10713
Блог
SSD диск использует алгоритмы равномерного "рассеивания" записи по микросхемам энергонезависимой памяти, что бы продлить срок службы диска. Безусловно, операции чтения и записи для фрагментированной таблицы на SSD диске будут выполняться быстрее, чем на жёстком диске. Мало того, на SSD диске (для большинства приложений) можно не обращать внимания на файловую фрагментацию, т.е. теперь можно смело размещать на одном диске (читай - массиве) несколько файлов данных и, что раньше считалось "махровой" крамолой, фалов журналов.
Природа фрагментации страниц данных и строк на страницах немного другая. Такая фрагментация приводит к увеличению числа операций ввода-вывода независимо от места нахождения страниц. Отсюда вполне логично, что компактное хранение будет эффективней поиска и слеплевания расщеплённых страниц. Однако, выигрыш не будет таким большим, как на жёстких дисках, поскольку выстроенные в строгой последовательности адресации страницы на SSD диске физически будут разбросаны по всему физическому пространству диска. Практика показывает, что требования к уровню фрагментации для SSD существенно снижаются.
28 сен 17, 12:29    [20828810]     Ответить | Цитировать Сообщить модератору
 Re: Есть ли смысл делать дефрагментацию индексов, расположенных на массиве из SSD дисков?  [new]
o-o
Guest
автор
теперь можно смело размещать на одном диске (читай - массиве) несколько файлов данных и, что раньше считалось "махровой" крамолой, фалов журналов

а что поменялось-то в плане живучести?
если диск помрет, а на нем и данные, и журнал, то все равно сдохнут все разом.
а если бы данные от журналов отделили,
первым подохло бы что-то одно.
и если это данные, то хотя бы можно снять tail of the log backup и восстановиться без потери данных.
так что отказываюсь понимать, зачем бы это логи с данными на один диск пихать.

все же не у всех AWAG, правда?
28 сен 17, 17:27    [20829791]     Ответить | Цитировать Сообщить модератору
 Re: Есть ли смысл делать дефрагментацию индексов, расположенных на массиве из SSD дисков?  [new]
o-o
Guest
*AOAG
28 сен 17, 17:29    [20829801]     Ответить | Цитировать Сообщить модератору
 Re: Есть ли смысл делать дефрагментацию индексов, расположенных на массиве из SSD дисков?  [new]
архивариус
Member

Откуда:
Сообщений: 149
o-o,

imho, тут только про производительность и дефрагментацию, про живучесть речь не шла
28 сен 17, 17:42    [20829856]     Ответить | Цитировать Сообщить модератору
 Re: Есть ли смысл делать дефрагментацию индексов, расположенных на массиве из SSD дисков?  [new]
Prolog
Member

Откуда: Москва
Сообщений: 2791
Александр Гладченко, спасибо. Всё, что вы написали, я не знал, поэтому для меня это очень ценная информация.
o-o, у нас файлы с данными и файл журнала транзакций расположены на разным массивах.

Но тогда возникли новые вопросы.
Массив RAID5 из 8 SSD. Не будем придираться к RAID5, но имеем средние значения: для Avg.Disk Queue Length - 121, Avg. Disk sec/Transfer - 0,055.
По аналогии с HDD делим 121 на 8 получаем ~15, что значительно больше 2х.

1й вопрос.
Насколько для SSD правомерено деление Avg.Disk Queue Length на кол-во дисков в массие и сравнение с 2ой? Администраторы утверждают, что для SSD такой метод не годится и цифра 121 это вполне нормально.

2й вопрос.
Для массивов HDD сами диски были намного медленне на запись/чтение, чем шины/каналы, по которым передавались данные на/с диска. Поэтому увеличение количества дисков в массиве приводило к увеличение скорости записи/чтения с диска.
Для быстрых SSD, как мне кажется, узким местом уже могут оказаться шины/каналы. И, поэтому, увеличение количества дисков в массиве не приведёт к росту производительности.
Если ли какой-нибудь предел на количество SSD дисков для PCIe и оптоволокна 2-16 Gbps, после которого увеличение количества дисков в массиве не даёт прибавку в скорости?
29 сен 17, 09:55    [20830887]     Ответить | Цитировать Сообщить модератору
 Re: Есть ли смысл делать дефрагментацию индексов, расположенных на массиве из SSD дисков?  [new]
iii2
Member

Откуда:
Сообщений: 202
Prolog
Для быстрых SSD, как мне кажется, узким местом уже могут оказаться шины/каналы. И, поэтому, увеличение количества дисков в массиве не приведёт к росту производительности.
Если ли какой-нибудь предел на количество SSD дисков для PCIe и оптоволокна 2-16 Gbps, после которого увеличение количества дисков в массиве не даёт прибавку в скорости?

Дык даже для небыстрых ссд - скорость записи порядка 500 МБайт в секунду, или 4 Гигабита в секунду.
Так что оптоволокно в 2 Гигабита уже в 2 раза уже диска.
А 8 дисков в RAID10 - уже шире, чем PCIex
Притом, что современные диски уже вплотную приближаются к гигабайту в секунду на запись/чтение.
29 сен 17, 10:25    [20830974]     Ответить | Цитировать Сообщить модератору
 Re: Есть ли смысл делать дефрагментацию индексов, расположенных на массиве из SSD дисков?  [new]
a_shats
Member

Откуда: Москва
Сообщений: 814
Prolog
Массив RAID5 из 8 SSD. Не будем придираться к RAID5, но имеем средние значения: для Avg.Disk Queue Length - 121, Avg. Disk sec/Transfer - 0,055.

А на какую конкретно нагрузку (чтение, запись) такая очередь ?
2й вопрос.
Для массивов HDD сами диски были намного медленне на запись/чтение, чем шины/каналы, по которым передавались данные на/с диска. Поэтому увеличение количества дисков в массиве приводило к увеличение скорости записи/чтения с диска.
Для быстрых SSD, как мне кажется, узким местом уже могут оказаться шины/каналы. И, поэтому, увеличение количества дисков в массиве не приведёт к росту производительности.
Если ли какой-нибудь предел на количество SSD дисков для PCIe и оптоволокна 2-16 Gbps, после которого увеличение количества дисков в массиве не даёт прибавку в скорости?

Бывает упор в RAID- контроллер, точнее, в его считалку (которая считает parity). Например, контроллеры SAS 6G в большинстве своем на количестве SSD свыше 4 заметного роста производительности в подобных массивах (RAID5, RAID6) не давали. Причем те, что первого поколения (LSI 2108, например - всякие MegaRAID 9260/9280 и иже с ними) - и на RAID10 тоже. То есть - да, если у Вас старый RAID-контроллер - упор может быть именно в него.
Не в каналы/шину (SATA SSD в большинстве своем все равно больше 540-550 МБпс на чтение и 500 на запись не дают) - а именно в контроллер.
И наоборот, подключаясь к СХД по FC Вы просто внесете дополнительную (хотя и почти незаметную в случае с FC) латентность: интерфейс-то к дискам от контроллеров у них всё равно SAS, причем у большинства - именно 6G, 12G имеют только относительно новые модели.
Ну и стоимость SAS SSD для СХД будет более, чем заметна.
29 сен 17, 12:07    [20831354]     Ответить | Цитировать Сообщить модератору
 Re: Есть ли смысл делать дефрагментацию индексов, расположенных на массиве из SSD дисков?  [new]
Александр Гладченко
Member

Откуда:
Сообщений: 10713
Блог
Prolog,
Если кратко, про указанные Вами метрики можно забыть для 99% реализаций. Следите за временем отклика, остальное скорее всего будет превосходить ваши потребности.
Для того, что бы не было узких мест, нужно учитывать архитектуру сервера и топологию коммуникаций от процессора до диска.
Сейчас практически все сервера в архитектуре NUMA. Узел NUMA = сокет. У каждого сокета своя шина, на которую можно подключить свой контроллер дисков или оптический/медный адаптер. Таким образом (выбирая сервер) вы можете масштабировать производительность шины.
Нынче модно подключать по оптике (которую уже разгоняют у Брокейда до 128Gbps) полки AllFlash. Пока ещё через FC транслируют последовательный SCSI, но уже почти все поголовно вендоры отказываются от SAS интерфейсов дисков, и именно потому, что он стал "узким" местом. Уже завтра по оптике "полетит" NVMe, который подключается к чипам MLC параллельно. Это снимет Ваши опасения и по поводу очередей и производительности отдельного массива. Сейчас же, вполне можно делать массивы с числом дисков не больше 6 (тогда производительность записи RAID5 догонит RAID10 с таким же числом дисков) и масштабироваться путём увеличения числа таких массивов и контроллеров их обслуживающих.
Кому то это бюджетом не поднять, но время идёт - цены снижаются ;) Например, за этот год цена на FUJITSU ETERNUS AF250 с дисками 1.9Тб снизилась вдвое.
29 сен 17, 12:20    [20831376]     Ответить | Цитировать Сообщить модератору
 Re: Есть ли смысл делать дефрагментацию индексов, расположенных на массиве из SSD дисков?  [new]
Prolog
Member

Откуда: Москва
Сообщений: 2791
Александр Гладченко
и масштабироваться путём увеличения числа таких массивов и контроллеров их обслуживающих

Спасибо, я тоже к этому склоняюсь и очень приятно, что есть аналогичное, но при этом аргументированное и авторитетное мнение.
29 сен 17, 13:31    [20831608]     Ответить | Цитировать Сообщить модератору
 Re: Есть ли смысл делать дефрагментацию индексов, расположенных на массиве из SSD дисков?  [new]
Makar4ik
Member

Откуда: Когда-то были Лужки, а теперь Бордюр-Сити.
Сообщений: 2676
...простите, кучу переписки пропустил.
Но дефраг индекса, и дефраг диска - это абсолютно разные вещи.
И да, на SSD дефраг индекса нужен так же, как и на HDD

...там не надо дефрага файлов, это да.
Но индекс, и его дефраг - это отдельная фишка.
30 сен 17, 00:59    [20832964]     Ответить | Цитировать Сообщить модератору
 Re: Есть ли смысл делать дефрагментацию индексов, расположенных на массиве из SSD дисков?  [new]
Makar4ik
Member

Откуда: Когда-то были Лужки, а теперь Бордюр-Сити.
Сообщений: 2676
..только для индекса "дефраг" называется reorganize
И там чуть хитрее. Если индекс по OLTP табличке, то свободного места надо оставить 10-20%.
А если по OLAP, то не более 1%
30 сен 17, 01:02    [20832970]     Ответить | Цитировать Сообщить модератору
 Re: Есть ли смысл делать дефрагментацию индексов, расположенных на массиве из SSD дисков?  [new]
aleksrov
Member

Откуда:
Сообщений: 948
Makar4ik
..только для индекса "дефраг" называется reorganize
И там чуть хитрее. Если индекс по OLTP табличке, то свободного места надо оставить 10-20%.
А если по OLAP, то не более 1%


Может быть и Rebuild. И зачем оставлять 10-20%? Не, если у вас оптимистичная модель или есть readable replica, тогда надо, а так, зависи от...
2 окт 17, 07:28    [20835238]     Ответить | Цитировать Сообщить модератору
Все форумы / Microsoft SQL Server Ответить