|
AlwaysOn, нода для чтения и ребилд индекса
|
||
|---|---|---|
Участник
Откуда: Moscow
Сообщения: 26 926 |
||
| 16.10.2020, 20:37 |
|
|
|
|
|
AlwaysOn, нода для чтения и ребилд индекса
|
|||
|---|---|---|---|
|
#18+
Добрый вечер. Несколько раз сталкивались с проблемой: кластер AlwaysOn, две ноды с синхронным коммитом. На основной запускается джоб обслуживания индексов, параметр Online = on включен. Обычно выполняется нормально, но иногда на вторичной ноде в это время запускают долгие отчёты (20+ минут) с параметром грязного чтения (но это не спасает). И если нужные индексы совпадают, то в этот долгий селект упирается сессия background от sa, которой нужно провести синхронизацию, при этом эта системная сессия накладывает блокировку пока ждёт, в неё упираются следующие пользовательские запросы и вскоре вторичная нода вся в блокировках. Быстро помогает либо тормознуть джоб на основной ноде, либо грохнуть долгий запрос на чтение на вторичной. Кроме варианта поднять третью ноду с асинхронной репликой для долгих отчётов кто-то решал схожую проблему? При этом желательно чтобы и планы обслуживания индексов проходили и возможность запуска долгих отчётов сохранялась в целом. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.10.2020, 22:23 |
|
||
|
AlwaysOn, нода для чтения и ребилд индекса
|
|||
|---|---|---|---|
|
#18+
Danion, авторследующие пользовательские запросы ожидают блокировку чего и какого типа? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.10.2020, 13:45 |
|
||
|
AlwaysOn, нода для чтения и ребилд индекса
|
|||
|---|---|---|---|
|
#18+
Владислав Колосов, У ожидающих lastwaittype - LCK_M_SCH_S, а waitresource - таблица по которой шла работа с индексом. Пока добавил костыльное решение - проверка на вторичной ноде каждую минуту в дни\часы работы обслуживания индекса и если больше 5 блокировок держится несколько минут, то стопать джоб индекса на первичной. На примерной тестовой симуляции нормально отработало, а в реальной посмотрим, такое не часто происходит. Но никого лишнего хоть не отключит. Приличное количество решений для проблемы с планами обслуживания, но если блокировки на том же сервере. Для варианта - на основной ноде всё ок, никаких блокировок, а вторичная встала - готовых решений и идей не нашёл. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.10.2020, 14:29 |
|
||
|
AlwaysOn, нода для чтения и ребилд индекса
|
|||
|---|---|---|---|
|
#18+
Danion, жалоб вроде бы у нас не было, это, возможно, типовая ситуация. Запросы чтения накладывают блокировки стабильности схемы. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.10.2020, 14:55 |
|
||
|
AlwaysOn, нода для чтения и ребилд индекса
|
|||
|---|---|---|---|
|
#18+
Если данные на SSD, не нужно делать ребилд индекса. Тогда и с зеркалом проблема отпадёт... Дефрагментация на SSD нужна только если много фантомных записей и фоновый процесс их не успевает вчищать. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.10.2020, 14:56 |
|
||
|
AlwaysOn, нода для чтения и ребилд индекса
|
|||
|---|---|---|---|
|
#18+
Регулярное перестроение индексов требуется для индексов с заполнением мене 100%, если это заполнение не с потолка взято, разумеется. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.10.2020, 15:12 |
|
||
|
AlwaysOn, нода для чтения и ребилд индекса
|
|||
|---|---|---|---|
|
#18+
Ну 2 раза в неделю вечером я часто не назову. Сейчас на SSD. Видел предложение, что типа теперь не нужно делать обслуживание индексов, но они удивляет. Есть селекты по РК таблицы, которые начинают работать медленнее, когда у индекса заполняемость страниц падает до 40%, а фрагментация 50%+ К тому же раньше вроде SQL Server переставал использовать сильно фрагментированные индексы, не знаю как сейчас с этим. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.10.2020, 15:27 |
|
||
|
AlwaysOn, нода для чтения и ребилд индекса
|
|||
|---|---|---|---|
|
#18+
Уточнение по запросу с индеком, в последний раз проблема была с reorganize, а не rebuild Код: sql 1. 2. 3. 4. 5. Используется процедура от Hallengren, вот % для запуска reorganize или rebuild я пожалуй подниму, базовые 10% для reorganize сейчас действительно не нужны. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.10.2020, 15:45 |
|
||
|
AlwaysOn, нода для чтения и ребилд индекса
|
|||
|---|---|---|---|
|
#18+
Регулярный ребилд на SSD тупо убийство дисков, чистый вред и никакой пользы! А теперь вопрос - почему? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.10.2020, 16:03 |
|
||
|
AlwaysOn, нода для чтения и ребилд индекса
|
|||
|---|---|---|---|
|
#18+
Александр Гладченко Регулярный ребилд на SSD тупо убийство дисков, чистый вред и никакой пользы! А теперь вопрос - почему? Тоже мне секрет Полишинеля. На ссд данные изначально "фрагментированы". ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.10.2020, 16:08 |
|
||
|
AlwaysOn, нода для чтения и ребилд индекса
|
|||
|---|---|---|---|
|
#18+
Александр Гладченко, Вы выступаете именно против ребилда индексов? Или за утверждение, что фрагментация на SSD дисках не влияет на производительность? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.10.2020, 16:29 |
|
||
|
AlwaysOn, нода для чтения и ребилд индекса
|
|||
|---|---|---|---|
|
#18+
Я ни за что не выступаю. Дефрагментация и ребилд - близнецы, братья. SSD используют алгоритм рассеивания записи, что бы продлить ресурс диска, т.к. число циклов перезаписи ячейки конечно. Т.е. последовательная запись превращается в случайную. Дефрагментация была изобретена для оптимизации работы с данными на жёстких дисках, где большинство времени тратилось на перемещение головок и поворот диска до нужного сектора. В SSD этого нет. Т.е. внешняя фрагментация - это на SSD не повод для беспокойства, если только у вас не огромное число фантомных записей. Внутренняя фрагментация лечится не ребилдом. У неё другие причины и другое влияние на производительность. А вот после того, что вы прочитали, должен выступать не я, а здравый смысл ;) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.10.2020, 18:50 |
|
||
|
AlwaysOn, нода для чтения и ребилд индекса
|
|||
|---|---|---|---|
|
#18+
...а вот в качестве гадалки я могу тут повыступать. Давайте угадаю, что случится если бездумно ребиодить все индексы с полным просмотром в один поток на SSD. Предсказание: все SSD диски в массиве умрут в один день, неожиданно и намного раньше своих более везучих собратьев, которых не перезаписывали так интенсивно. Если смотреть на такую "работу" глазами бухгалтера, то он бы навесил на всё это ярлык: ФИНАНСОВОЕ ПРЕСТУПЛЕНИЕ ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.10.2020, 19:05 |
|
||
|
AlwaysOn, нода для чтения и ребилд индекса
|
|||
|---|---|---|---|
|
#18+
Александр Гладченко SSD используют алгоритм рассеивания записи, что бы продлить ресурс диска, т.к. число циклов перезаписи ячейки конечно. Т.е. последовательная запись превращается в случайную. 1. Уменьшение количества операций, что должно повысить производительность Не знаю, конечно, на сколько это влияет, но теоретически ускорение должно быть. 2. Уменьшение износа SSD при обновлении данных, т.к. в SSD при записи маленького блока изменение делает копированием его в новый большой, вместе с окружающими данными. Это называется "усиление записи" (Write amplification) Т.е., например, если записать 64 кб одним блоком, то реально сотрётся 512 Кбайт, а если 8 блоков по 8 Кбайт в разных местах, то 8 раз по 512 Кбайт. Там, конечно, не совсем всё так примитивно, и зависит от собственно операций записи, но однозначно говорить про полую бесполезность дефрагментаций во всех случаях я бы не стал. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.10.2020, 20:37 |
|
||
|
AlwaysOn, нода для чтения и ребилд индекса
|
|||
|---|---|---|---|
|
#18+
alexeyvg, Не согласен ни с одним пунктом. Первый заметно поможет разве что ребилду. Второй не будет писать в одну ячейку только то, что нам хотелось бы. И читать тоже не будет только столько, сколько нам нужно для производительности. Но всё это не важно и получаемые задержки и производительность позволяют не париться на этот счёт. Пока я знаю только один сценарий, где это реально полезно, о нём было выше. Зато чтение реплики от очереди на Redo может стать бессмысленным из-за отставания. Ито не только ребилд так гадит. Понимаю, что сложно отказаться от стереотипов, потому и избрал такую форму подачи ;) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.10.2020, 12:40 |
|
||
|
AlwaysOn, нода для чтения и ребилд индекса
|
|||
|---|---|---|---|
|
#18+
Александр Гладченко, не сосем понятно, дефрагментация же уменьшит количество чтений, объём кеширования, колчиество блокировок и другие связанные вещи, разве это несущественно? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.10.2020, 19:26 |
|
||
|
AlwaysOn, нода для чтения и ребилд индекса
|
|||
|---|---|---|---|
|
#18+
Владислав Колосов, Вы заблуждаетесь. Так было раньше. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.10.2020, 00:06 |
|
||
|
AlwaysOn, нода для чтения и ребилд индекса
|
|||
|---|---|---|---|
|
#18+
Александр Гладченко, то есть современная фрагментация не оказывает влияния на объём хранения данных, я Вас правильно понял? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.10.2020, 02:40 |
|
||
|
AlwaysOn, нода для чтения и ребилд индекса
|
|||
|---|---|---|---|
|
#18+
Владислав Колосов, Простите, но я не понял, что у Вас написано. Есль речь о размерах файлов данных, то без дефрагментации они меньше. Если речь о внутренней фрагментации, то об этом вроде уже написал... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.10.2020, 10:51 |
|
||
|
AlwaysOn, нода для чтения и ребилд индекса
|
|||
|---|---|---|---|
|
#18+
Александр Гладченко, Александр, а кто призывает просто делать ребилд для всех баз и всех таблиц? Это и на HDD было не нужно, имхо. Существуют варианты, в том числе готовые, для проверки состояния индексов и запуска нужного варианта для каждого отдельно при достижении % фрагментации. Есть системы, где малейшее увеличение производительности важно и компании готовы платить за неё. Да и при точечном подходе так ли там растёт износ дисков. Есть пользовательские таблицы с промежуточными данными, которые каждый день миллионы строк перезаписывают. Ладно, раз уж от изначального вопроса с блокировками отошли. То обсудим влияние фрагментации на производительность при SSD дисках. Пока видел мнения, что на SSD дисках уже никак не влияет и вариант, что хотя влияние и уменьшилось, но всё ещё индексы с низкой фрагментацией лучше. Вроде SSD диски уже много лет, подробной разбора с экспериментами никто не проводил? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.10.2020, 09:43 |
|
||
|
AlwaysOn, нода для чтения и ребилд индекса
|
|||
|---|---|---|---|
|
#18+
Александр Гладченко, Я вот вслед за Владиславом Колосовым не понимаю: ребилд это ведь не только ценный мех выстраивание страниц по порядку - это еще и приведение индекса к сбалансированному состоянию. А если у меня, например, разбалансированное дерево индекса и много seek'ов внутри nested loops - я могу спокойно на этих seek'aх потерять несколько десятков процентов. Просто потому, что СУБД будет дольше "спускаться" до листовых записей. Разве не так? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.10.2020, 11:26 |
|
||
|
AlwaysOn, нода для чтения и ребилд индекса
|
|||
|---|---|---|---|
|
#18+
0wl А если у меня, например, разбалансированное дерево индекса В SQL нет разбалансированных деревьев, они все B(alanced) Tree Вообще в этом топике смешались два вида фрагментации 1. Логическая, она же внешняя, она же порядок страниц в индексе. Александр Гладченко говорит именно про бесполезность ребилда для устранения этого типа фрагментации на SSD. В общем и целом понятно на чем основано это утверждение, хотя и тут есть незатронутые моменты. Например,как в этом случае работает механизм read ahead. 2. Физическая, она же внутренняя, она же заполненность страниц. Тут все значительно сложнее Если такая фрагментация равномерна по всему индексу, и вызвана постоянными равномерными вставками, то ребилд с одной стороны выглядит как борьба с ветряными мельницами (вы уменьшаете эту фрагментацию, а она снова растет по естественным для системы причинам), с другой цена SSD по прежнему достаточно высока, и держать SSD заполненным на половину (как раз к 50% будет стремиться фрагментация в этом кейсе) накладно. Если такая фрагментация неравномерна, например, она вызвана переносом данных из одной части в другую (обычно с начала индекса в конец), то фрагментация, а точнее заполненность страниц, будет стремиться куда-то к 1 записи на страницу. В этом случае негативный эффект от нее возрастает многократно и ребилд необходим. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.10.2020, 12:01 |
|
||
|
AlwaysOn, нода для чтения и ребилд индекса
|
|||
|---|---|---|---|
|
#18+
msLex, 1. Дерево индекса сбалансировано сразу после перестроения (ну или создания). А потом мы начинаем в это дерево вставлять данные и оказывается, что в какие-то промежутки вставляем чаще, чем в другие. Эти популярные промежутки начинают чаще делиться, создавать дополнительные ветки под собой - и баланс дерева нарушается. Именно это я имел в виду под "разбалансированным" деревом - и в этом случае мы получаем, что пусть к "листьям" по одной ветке оказывается длиннее, чем по другой, куда данные добавляют реже. 2. read-ahead в SSD, по идее, никак не пострадает. Листовая страница знает, номера страниц до и после нее. В случае HDD мы бы долго ждали, пока он доберётся до следующей страницы, а с SSD у нас никакой разницы нет 3. Про последний пример вообще не понял. Если на странице недостаточно места для вставки данных, она делится на 2 новые страницы, данные между ними делятся пополам. Единственный вариант, где я могу представить себе "1 строку на 1 странице" - это "хвостовая" страница, которую добавили в самом конце индекса. Ну и это, по идее, не надолго - со временем ей добавят соседей ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.10.2020, 12:49 |
|
||
|
AlwaysOn, нода для чтения и ребилд индекса
|
|||
|---|---|---|---|
|
#18+
Danion, Вы хоть сами смотрели этот ролик? ...там чудным образом у него вначале получалось только опровергнуть себя же :) Я не буду коментировать результаты тестов производительности запросов, выполненные на ноутбуке. Жаль на это время тратить. Повторю одно, выигрыш от ребилда на современных серверах с хранилкой на SSD настолько мизерный, что им можно пренебречь. Я вот вред наносится серьёзный. Делайте ребилд только при явной необходимости. Перечислю вред по мере убывания влиияния на работу: 1. Безсмысленноое расходование циклов перезаписи SSD 2. Дополнительная нагрузка на REDO (мы же ещё помним тему топика) 3. Давление на память во время ребилда 4. Блокировка таблицы в момент переключения метаданных ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.10.2020, 12:57 |
|
||
|
|
start [/forum/topic.php?fid=46&fpage=45&tid=1685513]: |
0ms |
get settings: |
9ms |
get forum list: |
12ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
42ms |
get topic data: |
10ms |
get forum data: |
2ms |
get page messages: |
64ms |
get tp. blocked users: |
2ms |
| others: | 13ms |
| total: | 162ms |
| 0 / 0 |
