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

12.7.26

Page Life Expectancy — это не то, что вы думаете…

Автор: Paul Randal, Page Life Expectancy isn’t what you think…

Существует много споров о счётчике производительности Buffer Manager — Page Life Expectancy, в основном вокруг того, что люди продолжают цитировать 300 в качестве порога для начала беспокойства о проблеме (что в наши дни является полной ерундой). Это слишком низкое значение, чтобы быть точкой, на которой стоит начинать беспокоиться, если ваш PLE падает и остаётся на этом уровне. Джонатан предложил лучшее число, основанное на размере вашего буферного пула — см. нижнюю часть его статьи здесь.

Но не поэтому я пишу сегодня: я хочу объяснить, почему в настоящее время Page Life Expectancy в большинстве случаев не даёт вам полезной информации.

8.7.26

Ожидания SOS_SCHEDULER_YIELD и спин-блокировка LOCK_HASH

Автор: Paul Randal, SOS_SCHEDULER_YIELD waits and the LOCK_HASH spinlock

В этой статье я хотел бы показать пример возникновения ожиданий SOS_SCHEDULER_YIELD и того, как может показаться, что причиной является спин-блокировка.

Первоначально я опубликовал эту статью, а затем обсудил его с моим хорошим другом Бобом Уордом (Bob Ward) из службы поддержки продуктов, который усомнился в моих выводах, основываясь на своём опыте (спасибо, Боб!). После более глубокого исследования я обнаружил, что моя первоначальная версия была неверной, поэтому это исправленная версия.

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 оценят мою сдержанность в том, что я не сострил на тему «Это просто работает медленнее».

23.6.26

Шаблонные реакции на статистику ожиданий: SOS_SCHEDULER_YIELD

Автор: Paul Randal, Knee-Jerk Wait Statistics : SOS_SCHEDULER_YIELD

В этой статье я продолжу тему статистики ожиданий и расскажу об ожидании SOS_SCHEDULER_YIELD.

Когда SOS_SCHEDULER_YIELD является преобладающим на сервере, часто наблюдается устойчивое высокое использование ЦП. Шаблонная реакция здесь заключается в том, что сервер, должно быть, испытывает давление на ЦП или что проблема в спинблокировке.

22.6.26

Выявление запросов с ожиданиями SOS_SCHEDULER_YIELD

Автор: Paul Randal, Identifying queries with SOS_SCHEDULER_YIELD waits

Одна из проблем с типом ожидания SOS_SCHEDULER_YIELD заключается в том, что это на самом деле не тип ожидания. Когда возникает этот тип ожидания, это происходит потому, что поток исчерпал свой 4-миллисекундный квант планирования и добровольно уступил ЦП, перейдя непосредственно в конец очереди выполнения (Runnable Queue) для планировщика, минуя список ожидания (Waiter List). Однако ожидание должно быть зарегистрировано, когда поток покидает процессор, поэтому используется SOS_SCHEDULER_YIELD.

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 (т.е. без какого-либо простоя приложения).

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 часто опаснее, чем процент загрузки ЦП. 

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) или разработчиком, понимание и устранение этого типа ожидания поможет обеспечить работу вашей базы данных на пике эффективности.

24.4.26

Работают ли многоядерные процессоры лучше, чем одноядерные?

Автор: Paul Randal, Search Engine Q&A #5: Do multi-core CPUs perform better than single-core CPUs?

Вот интересный вопрос, который прислал мне мой друг Стив Джонс из SQL Server Central — будет ли один процессор с двумя ядрами работать лучше, чем два одноядерных процессора? Оба варианта имеют два вычислительных ядра, но аппаратная архитектура разная — какой из них обеспечит лучшую производительность SQL Server? Что ж, однозначного ответа нет — всё зависит от многих факторов! Я обсуждал эту тему с Джеромом Халмансом, бывшим коллегой по команде Storage Engine в SQL Server, и с его разрешения я основываю эту статью на нашем обсуждении.

29.10.25

SQL Server и большие страницы: подробное объяснение

Автор: Bob Ward, SQL Server and Large Pages Explained

В на Europe PASS Summit я читал доклад о диагностике памяти. В нём упомянул, что SQL Server будет использовать большие страницы (Large Pages), если включён trace flag 834. На конференции Кристиан Болтон, хорошо известный MVP из Великобритании, заметил, что видел в ERRORLOG сообщения о «large pages», хотя trace flag у него был выключен. Тогда я ответил, что не представляю, как такое возможно. Что ж, Кристиан, вы ничего не выдумали.

Вскоре тема всплыла снова, когда я помогал коллегам из CSS разбираться с тем же вопросом. Самое время углубиться и разобраться, что же там на самом деле происходит.

17.8.23

Новое в SQL Server 2022: Intelligent Query Processing — degree of parallelism feedback

Автор оригинала: Kate Smith - Senior Program Manager SQL Server 2022

Неэффективный параллелизм — досадная проблема, потому что старые методы обеспечения DOP неэффективны

Степень параллелизма (degree of parallelism - DOP), с которой выполняется запрос, может сильно повлиять на его производительность. Когда для запроса используется параллелизм, уместен вопрос, используется ли для запроса оптимальный уровень параллелизма. Если степень параллелизма слишком высока, это может стать причиной снижения эффективности выполнения запроса. Если степень параллелизма слишком низкая, это может привести к потере возможного выигрыша во времени исполнения запроса, который мог получиться при большем параллелизме. Для запроса можно задать максимальную степень параллелизма вручную, указав его с помощью подсказки MAXDOP, установив его на уровне конфигурации сервера или пула регулятора ресурсов. Однако, часто бывает что пользователи подбирают степень параллелизма вручную для каждого критичного для приложений запроса. В лучшем случае используется подсказка MAXDOP, когда проблему удаётся локализовать, но чаще всего даже не пытаются определить оптимальную степень параллелизма для каждого запроса из рабочей нагрузки,  а подбирается параметр конфигурации сервера max degree of parallelism (server configuration option).

21.4.23

Tips for DBA: Log Flush Performance

Одной из распространённых задач систем с высокой транзакционной загрузкой является определение того, достаточно ли производительна подсистема ввода-вывода, обслуживающая журнал транзакций. Часто «узким местом» становиться дисковая подсистема, используемая в качестве долговременного носителя для файла журнала транзакций обслуживаемой SQL Server базы данных. Одним из важных параметров дисковой подсистемы является время доступа к данным на диске. Современным дисковым подсистемам характерно время доступа порядка 1 – 5 ms. Проверить, какое время доступа у используемой для размещения файла журнала транзакций дисковой подсистемы можно с помощью административного динамического представления: sys.dm_os_wait_stats (Transact-SQL). Данные в этом представлении накапливаются с момента последнего запуска службы SQL Server, поэтому, рекомендуется очистить эту статистику.

Настройка Windows Server 2008/2003 x64 для обслуживания SQL Server 2008

По состоянию на 2009 год

Эта статья - вольная интерпретация рекомендаций: Microsoft, IBM, HP, Dell, QLogic, LSI, EMC, ACER, Bull, Fujitsu, Hitachi, NEC и Unisys. Некоторые рекомендуемые настройки требуют отдельного, обстоятельного разговора, и потому не включены в эту статью, а найти эти рекомендации можно в этом блоге.

20.4.23

Флаги трассировки для эталонного теста производительности TPC-C

По материалам статьи: Microsoft SQL Server 2005 TPC-C Trace Flags

Наиболее часто используемым способом изменения поведения SQL Server является выставление флагов трассировки. Следующие флаги трассировки поддерживаются в настоящее время Майкрософт для публикации результатов тесов производительности, таких как TPC-C. Если сотрудники Майкрософт рекомендуют Вам использовать другие флаги трассировки, которые не представлены в списке ниже, пожалуйста, сообщите об этом Джейми Редингу (Jamie.Reding@Microsoft.com) или Чарльзу Левину (Charles.Levine@Microsoft.com) до того, как вы опубликуете использование этих флагов.

Флаги трассировки для эталонного теста производительности TPC-E

По материалам статьи: Microsoft SQL Server 2008 TPC-E Trace Flags

Наиболее часто используемым способом изменения поведения SQL Server является выставление флагов трассировки. Следующие флаги трассировки поддерживаются в настоящее время Майкрософт для публикации результатов тесов производительности TPC-E. Если сотрудники Майкрософт рекомендуют Вам использовать другие флаги трассировки, которые не представлены в списке ниже, пожалуйста, сообщите об этом Джейми Редингу (Jamie.Reding@Microsoft.com) или Чарльзу Левину (Charles.Levine@Microsoft.com) до того, как вы опубликуете использование этих флагов.
Единственными поддерживаемыми для SQL Server 2008 флагами трассировки для TPC-E являются флаги: -T661 -T834 -T3502 -T8744.
Единственным поддерживаемыми для SQL Server 2008 параметрами запуска сервера для теста TPC-E являются параметры: -c -E -x, которые хорошо описаны в BOL.

18.4.23

Пример настройки Soft-NUMA

Сегодня получили широкое распространение многоядерные системы. Персональные компьютеры с четырьмя ядрами уже не редкость. Т.о. счастливые обладатели подобных многоядерных систем могут на практическом примере апробировать Soft-NUMA и как можно привязать к Soft-NUMA узлу порт сетевого протокола TCP/IP.

Повышение пропускной способности сетевых интерфейсов для SQL Server с помощью настройки параметров RSS

По материалам статьи: Кун Ченг (Kun Cheng) Maximizing SQL Server Throughput with RSS Tuning

Рецензенты: Thomas Kejser, Curt Peterson, James Podgorski, Christian Martinez, Mike Ruthruff
Перевод: Александр Гладченко
Технические редакторы перевода: Алексей Халяко, Ирина Наумова

Функциональность Receive-Side Scaling (RSS) впервые появилась в Windows 2003. Это нововведение было призвано повысить возможности масштабируемости операционной системы Windows, и этим предоставить новые возможности по обслуживанию большого сетевого трафика. Такой трафик характерен для систем, где SQL Server обслуживает OLTP нагрузку. Подробное описание того, какие усовершенствования RSS получила операционная система Windows 2008, можно узнать из отчёта - Receive-Side Scaling Enhancements in Windows Server 2008 и в блоге - Scaling Heavy Network Traffic with Windows.

13.4.23

Running SQL Server on Machines with More Than 8 CPUs per NUMA Node May Need Trace Flag 8048

По материалам статьи: Running SQL Server on Machines with More Than 8 CPUs per NUMA Node May Need Trace Flag 8048

Данная статья относится к следующим версиям SQL Sever: 2008, 2008 R2, 2012 и 2014. Первый вариант статьи был опубликован в 2011г.

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

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

20.1.23

SQL Server 2012 Database Engine Task Scheduling

Дата публикации: 13 августа 2013г.

Автор: Боб Дорр – главный эскалационный инженер поддержки SQL Server
По материалам статьи: How It Works: SQL Server 2012 Database Engine Task Scheduling

В течении последних лет в разных источниках были описаны алгоритмы работы планировщика SQL Server. В частности, в статье «The Guru’s Guide to SQL Server Architecture and Internals» есть глава, написанная разработчиком планировщика (Sameer) и Кеном Хендерсеном. Автор этой статьи иранее описывал некоторые технические детали алгоритмов планирования задач SQLServer.

Эта статья посвящена некоторым изменениям, которые появились в SQL Server 2012. Статья не претендует на охват всех нюансов (коих слишком много), вместо этого будет частично проиллюстрирована работа алгоритма в его современной реализации, что позволит вам лучше понимать поведение планировщика SQLServer . Автор допускает по тексту несколько вольную трактовку в описании алгоритмов, преследуя цель избавить статью от лишней официальности.