Показаны сообщения с ярлыком Performance. Показать все сообщения
Показаны сообщения с ярлыком Performance. Показать все сообщения

25.6.26

Логика принятия решения о размещении параллельных запросов в SQL Server

Автор: Bob Dorr - MS Principal SQL Server Escalation Engineer, SQL Server Parallel Query Placement Decision Logic

Недавно у меня состоялся разговор с Jonathan Kehayias из sqlskills.com о размещении рабочих потоков, принадлежащих параллельному запросу. Когда я расспрашивал людей и изучал код, я быстро обнаружил, что предположение всё ещё заключается в том, что используется «наименее загруженный узел» (Least Loaded Node), но это изменилось в SQL Server 2012, и осведомлённость об этом как у наших инженеров поддержки, так и у клиентов оставляет желать лучшего. В этой статье я освещаю различные варианты решений, доступные SQL Server 2012, 2014 и 2016.

24.6.26

Автоматическая soft-NUMA и ожидания SOS_SCHEDULER_YIELD в SQL Server

Автор: Erik Darling, Automatic Soft-NUMA and SOS_SCHEDULER_YIELD Waits In SQL Server

Автоматическая soft-NUMA (auto soft-NUMA) может приводить к увеличению ожиданий SOS_SCHEDULER_YIELD в больших системах с ограниченной конкурентностью больших параллельных запросов. В этой статье содержится воспроизведение проблемы и краткий анализ. Я надеюсь, что читатели из Microsoft оценят мою сдержанность в том, что я не сострил на тему «Это просто работает медленнее».

21.6.26

Советы и хитрости для высокой производительности FILESTREAM

Автор: Paul Randal, High-performance FILESTREAM tips and tricks

У меня было много вопросов о производительности FILESTREAM и о том, как заставить NTFS хорошо масштабироваться. Я только что закончил писать 30-страничный технический документ о FILESTREAM для команды SQL Server, который должен быть опубликован до конференции PASS 2008 в ноябре. Хотя мой технический документ не совсем о производительности, в нём есть длинный раздел о настройке системы для достижения высокой производительности FILESTREAM. В этой статье я хочу дать список рекомендаций, которые помогут вам добиться хорошей производительности. Все они более подробно описаны в техническом документе.

20.6.26

Могут ли ключи кластерного индекса с типом GUID вызывать фрагментацию некластерных индексов?

Автор: Paul Randal, Can GUID cluster keys cause non-clustered index fragmentation?

На встрече пользовательской группы я потратил некоторое время на объяснение того, как GUID могут вызывать фрагментацию как в кластерных, так и в некластерных индексах, даже если GUID специально не включён в ключ некластерного индекса. GUID — это, по сути, случайные значения (псевдослучайные в диапазонах, если генерируются с помощью NEWSEQUENTIALID), которые также уникальны. Их уникальность делает их привлекательными для многих разработчиков в качестве значения ключа, не понимая при этом того хаоса, который они могут вызвать в производственной среде с точки зрения фрагментации и низкой производительности запросов.

19.6.26

Насколько сложно выбрать правильные некластерные индексы?

Автор: Paul Randal, How hard is it to pick the right non-clustered indexes?

На собрании группы разработчиков .NET в Редмонде, и во время того, как Кимберли рассказывала о пропущенных и лишних индексах, возник следующий вопрос:

«Какой некластерный индекс лучше всего использовать для запроса с условием WHERE lastname = 'Randal' AND firstname = 'Paul' AND middleinitial = 'S'

Кимберли сказала, что для этого случая порядок ключей не имеет значения. Я подумал секунду, а затем возразил, сказав, что наиболее селективный столбец должен быть первым. Мы согласились обсудить это с группой в конце, но я подумал ещё немного и понял (и признался группе), что она права – мне следовало бы знать, что не стоит подвергать сомнению знания Кимберли об индексировании… :-)

16.6.26

Следует ли создавать несколько файлов для пользовательской базы данных на многопроцессорном сервере?

Автор: Paul Randal, Search Engine Q&A #12: Should you create multiple files for a user DB on a multi-core box?

На сайте SQLServerCentral.com развернулась очень интересная дискуссия о том, стоит ли создавать несколько файлов для пользовательской базы данных, потому что на сервере несколько ЦП. Я написал пару длинных ответов в ходе дискуссии и хотел продублировать их здесь, так как считаю, что это представляет широкий интерес.

15.6.26

Горячее добавление ЦП и маска привязки

Автор: Paul Randal, SQL Server 2008: Hot-Add CPU (and affinity masks)

Короткая заметка сегодня, так как я готовлюсь к выступлению на собрании пользовательской группы SQL Server в Тихоокеанском Северо-Западе сегодня вечером в кампусе Microsoft в Редмонде.

SQL Server 2005 представил концепцию горячего добавления памяти (hot-add memory) для динамической обработки рабочей нагрузки. SQL Server 2008 расширяет эти возможности, добавляя также горячее добавление ЦП (hot-add CPU). Начиная с SQL Server 2025 (17.x), функция горячего добавления ЦП не рекомендуется и планируется удалить в будущей версии SQL Server. «Горячее добавление» означает возможность установить ЦП в работающую машину и затем перенастроить SQL Server для использования этого ЦП ONLINE (т.е. без какого-либо простоя приложения).

6.6.26

Как влияет сжатие резервных копий на загрузку процессоров

Автор: Paul Randal, SQL Server 2008: Backup Compression CPU Cost

Я давно обещал написать о встроенном сжатии резервных копий (Backup Compression). Для этой статьи я расширил базу данных AdventureWorks до 322 МБ (случайный размер, но достаточно большой, чтобы получить приемлемое время выполнения на моём сервере). Я использовал системный монитор (System Monitor) для измерения времени ЦП в пользовательском режиме (%user-mode CPU time), а также пропускной способности резервного копирования и восстановления для сжатой и несжатой операций резервного копирования, а затем и восстановления.

4.6.26

Отслеживание DOP Feedback с помощью Extended Events

Автор: Vivek Janakiraman, SQL Server 2025 Series : Degree Of Parallelism (DOP) Feedback Explained with Real-Time Demo!

Настройка параллелизма всегда была одной из самых сложных задач оптимизации производительности SQL Server. Администраторы баз данных часто тратят часы на точную настройку параметров MAXDOP, пытаясь найти идеальный баланс между производительностью и потреблением ресурсов.

С выходом SQL Server 2025 эта задача значительно упрощается благодаря обратной связи по степени параллелизма (Degree of Parallelism Feedback, DOP Feedback) — мощной функции интеллектуальной обработки запросов, которая автоматически оптимизирует выполнение параллельных запросов.

В этой статье мы рассмотрим:

  • Что такое DOP Feedback
  • Как отслеживать её с помощью расширенных событий (Extended Events)
  • Демонстрацию в реальном времени с несколькими сценариями
  • Как проверить, работает ли DOP Feedback на вашем сервере

3.6.26

Когда процессоры голодают

Автор: Luca Biondi, SQL SERVER. A deep analysis on CPU Starvation

Почему сервер при загрузке ЦП 40% может вести себя как при полностью утилизированных процессорах

Глубокое погружение в справедливость планировщика SOS, сборку мусора Hekaton, сканирование хэш-индексов и почему накопительное обновление CU5 для SQL Server имеет гораздо большее значение, чем думает большинство администраторов баз данных.

В двух словах

  • SQL Server использует кооперативное планирование через планировщик SOS (SOS Scheduler), и рабочие процессы должны добровольно уступать ЦП (yield).
  • Накопительное обновление SQL Server CU5 улучшает справедливость планировщика (scheduler fairness) во время сканирования сборки мусора хэш-индексов в In-Memory OLTP. 
  • Голодание ЦП (CPU starvation) может происходить даже тогда, когда общее использование ЦП выглядит умеренным. 
  • Неправильный размер корзин (bucket sizing) хэш-индексов и длинные цепочки версий могут резко увеличить затраты на обход сборщика мусора. 
  • Постоянный рост runnable_tasks_count часто опаснее, чем процент загрузки ЦП. 

2.6.26

Структуры хранения #4 – Memory-optimized columnstore


Автор: Hugo Kornelis, Storage structures 4 – Memory-optimized columnstore;

Настало время для следующей части моей серии о структурах хранения. Предыдущие части охватывали дисковое хранение строк, колоночные индексы и оптимизированное для памяти хранение. В этой части я рассмотрю комбинацию двух последних: оптимизированные для памяти колоночные индексы.

Оптимизированные для памяти колоночные индексы были представлены в SQL Server 2016. За это время я видел несколько эффектных маркетинговых презентаций Microsoft, в которых много говорилось о «аналитике в реальном времени» (real-time operational analytics). Новая тенденция, согласно которой аналитическая обработка больше не должна выполняться на устаревшей копии данных в отдельном хранилище, а непосредственно в OLTP-базе данных. Отчёты всегда были бы полностью актуальными, необходимость в ETL-конвейере отпала бы, а благодаря сочетанию оптимизированных для памяти структур для OLTP-нагрузок и колоночных индексов для аналитической обработки всё всегда было бы быстро. В теории.

Я больше не слышал термин «аналитика в реальном времени» после первоначального выпуска SQL Server 2016. А начиная с внедрения SQL Server 2017, я не припомню, чтобы слышал от кого-либо из сотрудников Microsoft использование терминов «оптимизированный для памяти» и «колоночный» в одном докладе, не говоря уже об одном предложении.

Я действительно не знаю, есть ли в мире клиенты, которые действительно используют оптимизированные для памяти колоночные индексы в своих производственных системах, и я серьёзно размышлял, стоит ли вообще включать эту структуру хранения в свою серию. Но я перфекционист. Поэтому я всё равно пишу о ней.

28.5.26

Обходим шторм компиляций стороной

Автор: Luca Biondi, Check SQL Server Plan Cache Pollution (III) in 45 Seconds

Вы когда-нибудь задумывались, почему ваш ЦП достигает 100% при низком объёме запросов? В этой статье я разберу механизм «Штормов компиляции» (Compilation Storms) и покажу, как обнаружить узкие места типа SOS_CACHESTORE менее чем за минуту.

В двух словах

  • Стоимость компиляции (Compilation Cost): Такты ЦП тратятся впустую, когда SQL Server выполняет «Полную оптимизацию» (Full Optimization) многократно.
  • Тривиальные планы (Trivial Plans): Быстрый путь к выполнению, который пропускает оптимизацию на основе стоимости для простых запросов.
  • Триггеры перекомпиляции (Recompilation Triggers): Плохая статистика и изменения схемы (DDL) являются основными подозреваемыми в нестабильности кэша.
  • Предупреждение о спинблокировке (Spinlock Warning): Высокое время ожидания SOS_CACHESTORE означает интенсивную конкуренцию за кэш планов.

Управление высококонкурентной средой SQL Server — это игра на миллиметры. Мы часто говорим о «быстрых запросах», но редко говорим о налоге, который движок платит до того, как запрос вообще начнётся: о компиляции. Когда ваш кэш планов нестабилен, SQL Server входит в «Шторм компиляции», превращая ваши высококлассные ЦП в дорогие обогреватели. Давайте заглянем под капот.

26.5.26

Выметаем ядовитые планы из кэша SQL Server


Автор: Luca Biondi, Check SQL Server Plan Cache Pollution (II) in 45 Seconds

Вы исправили ad-hoc запросы, но ваш сервер всё ещё «колбасит»? В этой статье я расскажу, почему даже идеальная параметризация может привести к «токсичности повторного использования» (reuse toxicity) и массовым скачкам ЦП.

В двух словах

  • Параметризованное засорение (Parameterized Pollution): Засорение кэша — это не только «слишком много планов», но и повторно используемый «неправильный план». 
  • Токсичность повторного использования (Reuse Toxicity): План, оптимизированный для одной строки, принудительно применяется к набору из миллиона строк, убивая производительность.
  • Нестабильность планов (Plan Instability): Резкие колебания между min_worker_time и max_worker_time указывают на войну, вызванную Sniffing'ом параметров.
  • Решение: Используйте Query Store, идентификацию по query_hash и оптимизацию PSP в SQL Server 2022.

В предыдущей части этой серии мы очистили кэш от «мусорных» планов. Но горькая правда в том, что чистый код не гарантирует чистый кэш. Даже когда ваше приложение на 100% параметризовано, SQL Server всё ещё может страдать от другого вида засорения — логической токсичности. Это происходит, когда движок повторно использует неоптимальный план выполнения, потому что во время компиляции он «унюхал» (sniffed) непредставительный параметр.

25.5.26

Проверка кэша SQL Server на засорение одноразовыми планами


Автор: Luca Biondi, Check SQL Server Plan Cache Pollution (I) in 45 Seconds

В этой статье я покажу вам, как «одноразовые» планы выполнения незаметно захватывают оперативную память вашего сервера и как остановить эту утечку памяти менее чем за минуту.

В двух словах

  • Загрязнение кэша планов (Plan Cache Pollution) происходит, когда непараметризованные запросы создают тысячи бесполезных одноразовых планов выполнения. 
  • Вымывание памяти (Memory Starvation): Эти планы крадут пространство у буферного пула, вытесняя данные из памяти и увеличивая ввод-вывод. 
  • Исправление: Используйте параметризацию, sp_executesql или включите настройку «Optimize for Ad Hoc Workloads». 
  • SQL-запрос «Wow!»: Определите, какие именно ad-hoc запросы прямо сейчас засоряют ваш кэш. 

За 25 лет настройки производительности я видел, как миллионы долларов, вложенных в оборудование, оказывались бесполезными из-за плохих привычек кодирования. Один из самых распространённых молчаливых убийц — засорение кэша планов. Это технический эквивалент заполнения библиотеки идентичными книгами, в которых меняется только одна страница. Каждый раз, когда ваше приложение отправляет запрос вроде WHERE Id = 1, а затем WHERE Id = 2 без параметризации, SQL Server обрабатывает их как совершенно новую логику.

24.5.26

Оптимизация производительности SQL Server с помощью тестирования дисков


Автор: Steve Stedman, CrystalDiskMark: Optimize SQL Server Performance with Disk Benchmarking

Скорость и эффективность вашей системы хранения напрямую влияют на то, насколько быстро SQL Server сможет выполнять запросы, управлять транзакциями и обрабатывать резервные копии. Игнорирование этого критически важного компонента может привести к неприятным узким местам, которые затронут всю среду базы данных.

22.5.26

Адаптивные соединения (Adaptive Joins) и распределение памяти в SQL Server

Автор: Kendra Little, Adaptive Joins and Memory Grants in SQL Server

Адаптивные соединения (adaptive joins) позволяют оптимизатору выбирать между хэш-соединением (Hash Join) и соединением вложенными циклами (Nested Loop join) во время выполнения, что может быть фантастически полезно для производительности, когда оценки количества строк могут варьироваться. Недавно, когда Эрик Дарлинг (Erik Darling) преподавал двухдневный курс по T-SQL на PASS Community Data Summit, один из студентов спросил, почему план запроса, в котором адаптивное соединение во время выполнения использовало вложенные циклы, всё равно получило большое распределение памяти (memory grant).

Я не помнила ответа на этот вопрос, но замечательная вещь в совместном преподавании в том, что Эрик его знал: адаптивные соединения всегда начинают выполняться как хэш-соединения, а это означает, что они должны получить распределение памяти заранее. Даже если в итоге запрос переключается на вложенные циклы во время выполнения, это распределение памяти уже было выделено. Это имеет реальные последствия для использования памяти, особенно в средах с высокой конкурентностью (high-concurrency environments).

21.5.26

Когда TempDB растёт «вширь»: как RCSI и длинные транзакции незаметно разрушают SQL Server


Автор: Steve Stedman, When TempDB Grows “Up and to the Right”: How RCSI and Open Transactions Quietly Break SQL Server

Одна из самых опасных проблем SQL Server — та, которую вы не замечаете, пока диск не заполнится, а производственная система не упадёт. TempDB особенно хороша в таком типе отказа — она незаметно растёт в фоновом режиме, пока внезапно не становится проблемой для всех.

Недавно мы просматривали отчёт о распределении пространства TempDB (TempDB Allocation History Report), и он прекрасно проиллюстрировал проблему, с которой мы сталкиваемся всё чаще по мере того, как растёт применение READ COMMITTED Snapshot Isolation (RCSI). RCSI обычно является правильным выбором, но когда что-то идёт не так, TempDB может расти взрывным образом, и большинство команд не понимают почему, пока не становится слишком поздно.

20.5.26

«Нет, мы не обновляемся. Что мы упускаем?»

Автор: Thomas Rushton, “No, we’re not upgrading. What are we missing out on?”

SQL Server 2016 — покойся с миром, RIP, скатертью дорога (хотя последнее звучит как-то слишком сурово). SQL Server 2016 выходит из расширенной поддержки (extended support) 14 июля — в День взятия Бастилии, без комментариев — 2026 года. Это следует из политики фиксированного жизненного цикла Microsoft (Fixed Lifecycle Policy): выпуск, примерно пять лет основной поддержки (mainstream support), в течение которой вы получаете исправления, обновления безопасности, улучшения производительности и функциональности, и ещё примерно пять лет расширенной поддержки (extended support), в течение которой вы получаете обновления безопасности и не многое другое. После этой даты Microsoft крайне редко выпускает какие-либо обновления за пределами платной программы расширенных обновлений безопасности (Extended Security Update, ESU), поэтому продолжение использования продукта, срок поддержки которого истёк (EOL product), следует рассматривать как экстренную меру только для краткосрочного использования.

19.5.26

Чего ждёт SOS_SCHEDULER_YIELD в SQL Server: причины и реакция


Автор: Steve Stedman, Decoding SOS_SCHEDULER_YIELD Wait Type in SQL Server: Causes and Solutions

Узнайте о типе ожидания SOS_SCHEDULER_YIELD в SQL Server: выявите причины, такие как конкуренция за ЦП, и найдите решения для настройки производительности с помощью экспертных советов. Этот тип ожидания возникает, когда задача добровольно уступает своё время ЦП, чтобы позволить другим задачам выполняться, что является естественной частью модели кооперативного планирования SQL Server. Однако, когда эти ожидания становятся частыми или продолжительными, они могут указывать на глубинные проблемы, ухудшающие производительность системы, что делает критически важным понимание их последствий.

По своей сути, SOS_SCHEDULER_YIELD отражает давление на ресурсы ЦП, поскольку задачи выстраиваются в очередь для выполнения. Хотя случайные уступки ожидаемы в загруженной среде, чрезмерные ожидания могут указывать на конкуренцию за ЦП, плохо оптимизированные запросы или даже аппаратные ограничения. Определение того, является ли этот тип ожидания симптомом более серьёзной проблемы, требует системного подхода к мониторингу и анализу, что в конечном итоге может привести к значительному повышению производительности.

В этой статье мы разберём тип ожидания SOS_SCHEDULER_YIELD, изучим его причины и то, когда он становится проблемой для вашей среды SQL Server. Мы проведём вас через методы диагностики, чтобы выявить корневые проблемы, и предоставим практические решения для снижения их влияния. Будь вы администратором баз данных (DBA) или разработчиком, понимание и устранение этого типа ожидания поможет обеспечить работу вашей базы данных на пике эффективности.

18.5.26

Неудобная правда о скалярных функциях


Автор: Luca Biondi, The Dangerous Truth About Scalar Functions in 45 Seconds

Скалярные пользовательские функции (Scalar UDF) — это тихие убийцы производительности SQL Server. В этой статье я расскажу, почему они скрывают свою истинную стоимость и как превращают быстрый запрос в покадровую катастрофу.

В двух словах

  • Скалярные UDF принудительно вызывают покадровое выполнение (RBAR — Row-By-Agonizing-Row): они обходят мощные алгоритмы оптимизатора, основанные на работе с наборами данных. 
  • Подавление параллелизма (Parallelism): Традиционные скалярные функции заставляют весь ваш запрос выполняться в одном потоке. 
  • Скрытые затраты: Планы выполнения часто показывают стоимость UDF как 0%, маскируя огромные накладные расходы на ЦП. 
  • Исправление: Используйте встроенные табличные функции (Inline Table-Valued Functions, iTVF) или функцию встраивания скалярных функций (Scalar Inlining), появившуюся в SQL Server 2019+.