Комментарии 24
Если память не изменяет, то в 2016 флаги 1118 и 4199 уже отжили свое, в них нет необходимости.
А у вас нет опыта в использование типовых флагов в синхронном режиме AlwaysOn? И с регламентными работами? А то некоторые там чуть ли не шаманят.
А у вас нет опыта в использование типовых флагов в синхронном режиме AlwaysOn? И с регламентными работами? А то некоторые там чуть ли не шаманят.
Потому я и указал, что важно учитывать версию MS SQL Server.
Обычно используют асинхронный режим AlwaysOn. Типовые регламентные работы и флаги такие же
Обычно используют асинхронный режим AlwaysOn. Типовые регламентные работы и флаги такие же
В асинхронном автоматически не переключится на реплику без потери данных. Если это не важно, то, понятное дело, асинхронный оптимальнее с точки зрения требований.
Про 2016 я уточнил только потому что Вы в конце отдельно приводили флаги не актуальные для новых версий. А так, конечно, надо внимательно перечитывать нюансы под конкретный релиз.
Про 2016 я уточнил только потому что Вы в конце отдельно приводили флаги не актуальные для новых версий. А так, конечно, надо внимательно перечитывать нюансы под конкретный релиз.
1224 — Отключает укрупнение блокировок на основе количества блокировок.
Контролирует ли этот флаг выбор между блокировками строк и страниц?
Периодически ловим дедлоки, где 3-5 не связанных друг с другом логически процессов по кругу лочатся из-за обновления строк в одной и той же таблице, находящихся похоже на одной странице. И непонятно как их побороть.
Или может какой-нибудь другой флаг или настройка могут помочь. В попадающейся в отчете дедлока хранимке уже давно написан rowlock, но он похоже игнорируется, плюс его нет в сотнях других запросов, которые приходят через ормку из приложения.
Т к деталей нет, то в общем рекомендую рассмотреть следующие варианты:
1) включить версионирование (самое простое)
2) воспользоваться секционированием, чтобы данные находились в разных секциях (среднее по сложности)
3) с помощью шардинга отправлять запросы на разные узлы (самое сложное)
1) включить версионирование (самое простое)
2) воспользоваться секционированием, чтобы данные находились в разных секциях (среднее по сложности)
3) с помощью шардинга отправлять запросы на разные узлы (самое сложное)
Из деталей могу сказать, что это ПО для небольшого банка, там секционированием и шардированием заниматься на текущий момент избыточно, дедлоки вылетают нечасто, и скорее всего когда из-за сбоев в статистике некоторые планы становятся параллельными со сканами там, где не нужно, и висят такие в кэше, пока мы не замечаем проблемы.
Ну и из того, что я не понимаю, в репортах таких круговых дедлоков всегда присутствуют типы ожиданий e_waitPortOpen и e_waitPipeGetRow. И если второй это из параллелизма, то откуда первый не совсем понятно.
Сейчас вот подумываю может попробовать поиграться с параллелизмом как описано в статье, но немного страшновато :)
А изоляция уже давно на снепшотах, если вы про это.
Ну и из того, что я не понимаю, в репортах таких круговых дедлоков всегда присутствуют типы ожиданий e_waitPortOpen и e_waitPipeGetRow. И если второй это из параллелизма, то откуда первый не совсем понятно.
Сейчас вот подумываю может попробовать поиграться с параллелизмом как описано в статье, но немного страшновато :)
А изоляция уже давно на снепшотах, если вы про это.
Да, я про изоляцию имел в виду.
Про параллелизм-начните с самого запроса, ограничив ему потоки от 1 и далее, сравните планы и время выполнения. Лучше сначала проверить на нагрузочной тестовой среде, а потом на проде
Про параллелизм-начните с самого запроса, ограничив ему потоки от 1 и далее, сравните планы и время выполнения. Лучше сначала проверить на нагрузочной тестовой среде, а потом на проде
Так по сканам-индексов не хватает или может они сильно фрагментированы, или статистика устаревшая
А чего страшно то?
Максимум, что вы получите — деградацию производительности в N раз (причем, думаю, N не будет больше 1,5-2 раз, максимум 3).
Вообще, Max Degree Parallelism в 0 оставляют только самоубийцы.
Это имеет смысл делать только в случае, если сервер используется как однопользовательская система для построения каких либо отчетов.
Другое дело, что в 1 его тоже стоит устанавливать не всегда.
Опять же, только в том случае, только когда вы имеете OLTP с тысячами одновременных коннектов и элементарными запросами, дергающими по 1 записи в таблице, без какой-либо сложно логики.
У меня, например — небольшие, 100 — 200 Гб базы, и небольшая, интенсивность обращения к ним, не более 100 запросов в секунду. Я установил степень параллелизма равной 1/4 количества «железных» ядер процессора, и, в общем, забыл об этой проблеме.
Наверное, можно сделать лучше, но зачем? :-)
Пользователи ж не кричат «висит», а только «подтормаживает».
:-)
Максимум, что вы получите — деградацию производительности в N раз (причем, думаю, N не будет больше 1,5-2 раз, максимум 3).
Вообще, Max Degree Parallelism в 0 оставляют только самоубийцы.
Это имеет смысл делать только в случае, если сервер используется как однопользовательская система для построения каких либо отчетов.
Другое дело, что в 1 его тоже стоит устанавливать не всегда.
Опять же, только в том случае, только когда вы имеете OLTP с тысячами одновременных коннектов и элементарными запросами, дергающими по 1 записи в таблице, без какой-либо сложно логики.
У меня, например — небольшие, 100 — 200 Гб базы, и небольшая, интенсивность обращения к ним, не более 100 запросов в секунду. Я установил степень параллелизма равной 1/4 количества «железных» ядер процессора, и, в общем, забыл об этой проблеме.
Наверное, можно сделать лучше, но зачем? :-)
Пользователи ж не кричат «висит», а только «подтормаживает».
:-)
никогда не занимался MS SQL
решение использовать в одном выражении все типы скобочек вызывает оторопь :-\
решение использовать в одном выражении все типы скобочек вызывает оторопь :-\
Первым показателем нехватки оперативной памяти является тот случай, когда экземпляр MS SQL Server съедает всю выделенную ему ОЗУ.
А экземпляр MS SQL SERVER всегда съедает всю выделенную ему ОЗУ.
:-)
Часто, но невсегда.
В статье изложено как понять, что именно ОЗУ ему не хватает, а не случай, когда СУБД что-то в памяти держит
В статье изложено как понять, что именно ОЗУ ему не хватает, а не случай, когда СУБД что-то в памяти держит
Часто, но невсегда.
Всегда, всегда. :-)
Хотя, конечно, если у вас памяти — ведро, а база — считанные мегабайты, тогда да.
Но вопрос в другом.
А почему б, в качестве первого шага по анализу «чего в супе не хватает» не воспользоваться более штатными средствами?
Штатным отчетом Memory Consumption, отчетами из серии Performance — Top Queries by ХХХХ или Activity Monitor (дада!) в SSMS?
Их, правда, нужно научиться читать.
Если Вы для мониторинга пользуетесь Activity Monitor, то тогда Вы будете заблуждаться, когда скулю нужно еще памяти, а когда он просто ее сьел (последнее не означает нехватку ОЗУ).
Activity Monitor перестал пользоваться лет 5 назад, т к есть более гибкие и точные способы получить что нужно (например про нехватку памяти описано выше).
Про встроенные отчеты я вообще молчу-когда начинаешь разбирать как это все собирается, то понимаешь, что лучше более точные запросы написать, оформить их в пользовательские счетчики и вывести их в Zabbix и Spotlight.
Наверно Вы никогда не сталкивались, когда из-за Activity Monitor и особенно из-за Сборщика Данных (а он нужен для тех красивых отчетов) высоконагруженная СУБД теряла в своей ппоизводительности более 5%, что недопустимо, где каждые 5 мсек стоят больших денег.
Для справки-работаю с разными БД от 100 МБ до 100+ ГБ с интенсивностью использования одновременных запросов от 10 до 10 000
Activity Monitor перестал пользоваться лет 5 назад, т к есть более гибкие и точные способы получить что нужно (например про нехватку памяти описано выше).
Про встроенные отчеты я вообще молчу-когда начинаешь разбирать как это все собирается, то понимаешь, что лучше более точные запросы написать, оформить их в пользовательские счетчики и вывести их в Zabbix и Spotlight.
Наверно Вы никогда не сталкивались, когда из-за Activity Monitor и особенно из-за Сборщика Данных (а он нужен для тех красивых отчетов) высоконагруженная СУБД теряла в своей ппоизводительности более 5%, что недопустимо, где каждые 5 мсек стоят больших денег.
Для справки-работаю с разными БД от 100 МБ до 100+ ГБ с интенсивностью использования одновременных запросов от 10 до 10 000
Даже если база считанные мегабайты, но нагрузка в 1000+ пользователей — съест.
НЛО прилетело и опубликовало эту надпись здесь
Да, имелось в виду, что сверху и снизу обьем ОЗУ ограничили в настройках.
И часто скуль осваивает выделенный ему максимальный обьем. Но сколько он сьел и мало ли ему обьемов ОЗУ-это разные вещи.
Также не стоит забывать, что версия и редакция могут накладывать максимально воспринимаемый обьем ОЗУ и ядер ЦПУ.
И часто скуль осваивает выделенный ему максимальный обьем. Но сколько он сьел и мало ли ему обьемов ОЗУ-это разные вещи.
Также не стоит забывать, что версия и редакция могут накладывать максимально воспринимаемый обьем ОЗУ и ядер ЦПУ.
Вот не знаю стоит ли вставлять в PROD столько флагов. Если что при поддержке Майкрософт не может сказать айяйяй? Я в данном случае консервантор, не ставь флаг пока не доказано, что есть проблема, которую он решает
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Некоторые аспекты мониторинга MS SQL Server. Рекомендации по настройке флагов трассировки