Автор: Paul Randal, Knee-Jerk Wait Statistics : SOS_SCHEDULER_YIELD
В этой статье я продолжу тему статистики ожиданий и расскажу об ожидании SOS_SCHEDULER_YIELD.
Когда SOS_SCHEDULER_YIELD является преобладающим на сервере, часто наблюдается устойчивое высокое использование ЦП. Шаблонная реакция здесь заключается в том, что сервер, должно быть, испытывает давление на ЦП или что проблема в спинблокировке.
Автор: Paul Randal, Identifying queries with SOS_SCHEDULER_YIELD waits
Одна из проблем с типом ожидания SOS_SCHEDULER_YIELD заключается в том, что это на самом деле не тип ожидания. Когда возникает этот тип ожидания, это происходит потому, что поток исчерпал свой 4-миллисекундный квант планирования и добровольно уступил ЦП, перейдя непосредственно в конец очереди выполнения (Runnable Queue) для планировщика, минуя список ожидания (Waiter List). Однако ожидание должно быть зарегистрировано, когда поток покидает процессор, поэтому используется SOS_SCHEDULER_YIELD.
Эти ожидания стоит исследовать, если они преобладают на вашем сервере, так как они могут указывать на выполнение больших сканирований данных, которые уже находятся в памяти, в то время как вы бы предпочли маленькие поиски по индексу.
Проблема в том, что они не являются настоящим типом ожидания, поэтому вы не можете использовать мой скрипт для просмотра sys.dm_os_waiting_tasks и получения планов запросов потоков, вызывающих этот тип ожидания, потому что эти потоки не ожидают ресурса и поэтому не отображаются в выводе sys.dm_os_waiting_tasks!
Решение — использовать динамическое административное представление sys.dm_exec_requests, так как оно показывает last_wait_type для всех выполняющихся запросов. Ниже приведён скрипт, который можно использовать.
SELECT
[er].[session_id],
[es].[program_name],
[est].text,
[er].[database_id],
[eqp].[query_plan],
[er].[cpu_time]
FROM sys.dm_exec_requests [er]
INNER JOIN sys.dm_exec_sessions [es] ON
[es].[session_id] = [er].[session_id]
OUTER APPLY sys.dm_exec_sql_text ([er].[sql_handle]) [est]
OUTER APPLY sys.dm_exec_query_plan ([er].[plan_handle]) [eqp]
WHERE
[es].[is_user_process] = 1
AND [er].[last_Wait_type] = N'SOS_SCHEDULER_YIELD'
ORDER BY
[er].[session_id];
GO
Этот скрипт покажет вам код и план запроса того, что происходит, но даже с этим может быть неочевидно, какой именно оператор вызывает это ожидание, поэтому вам может потребоваться прибегнуть к захвату стеков вызовов SQL Server, как я объясняю в ссылке на блог выше.
Этот тип ожидания возникает, когда поток смог выполниться в течение полного кванта времени (4 миллисекунды во всех версиях SQL Server, неизменяемо) и поэтому добровольно уступил планировщик, переместившись в конец очереди выполнения (Runnable Queue) своего планировщика. Хотя поток сразу переходит в состояние RUNNABLE, он не попадает в список ожидания (Waiter List), потому что ему не нужно ожидать ресурса. Несмотря на то, что потоку не нужно ждать, он должен зарегистрировать тип ожидания при переключении контекста с процессора, и этим типом является SOS_SCHEDULER_YIELD.
(Описание из Books Online: «Возникает, когда задача добровольно уступает планировщик для выполнения других задач. Во время этого ожидания задача ждёт возобновления своего кванта.»)
Существуют различные шаблонные реакции на этот тип ожидания:
SOS_SCHEDULER_YIELD.Наиболее распространённая причина ожиданий SOS_SCHEDULER_YIELD, которую я вижу, — это запросы, выполняющие сканирование страниц, которые находятся в памяти и не изменяются, следовательно, нет конкуренции за доступ к страницам, и поток сканирования может выполняться, пока не исчерпает свой квант времени. Это может быть связано с тем, что план запроса ошибочно выполняет сканирование таблицы, или это может быть нормальной частью вашей рабочей нагрузки. Как и в случае с ожиданиями CXPACKET, не делайте поспешного вывода, что ожидания SOS_SCHEDULER_YIELD — это плохо.
Я написал большую статью о понимании и устранении ожиданий SOS_SCHEDULER_YIELD на sqlperformance.com, которая более подробно объясняет планирование потоков и исчерпание квантов, а также устранение неполадок. В основном это включает идентификацию запроса, который вызывает ожидания SOS_SCHEDULER_YIELD, и проверку того, что план запроса выглядит корректным (например, отсутствует ли некластерный индекс, вызывающий сканирование таблицы в памяти?). Обратите внимание, что запросы, вызывающие ожидания SOS_SCHEDULER_YIELD, не отображаются в sys.dm_os_waiting_tasks, поэтому вам нужен скрипт, который использует sys.dm_exec_requests — и такой скрипт есть в этой статье выше.
Когда квант времени потока истекает, поток обязан уступить процессор. Он не имеет информации о других потоках на этом планировщике, и всегда происходит переключение контекста, когда поток переходит в конец очереди выполнения, даже если он единственный поток на планировщике. Поток не может решить просто не уступать. Именно переключение контекста заставляет регистрировать тип ожидания внутри SQLOS. Если переключение контекста не происходит (потому что поток не проверяет, истёк ли квант), это невыполняющий уступку планировщик (non-yielding scheduler), и вы увидите сообщение 17883 в журнале ошибок.
Ожидания SOS_SCHEDULER_YIELD всегда имеют нулевой компонент ожидания ресурса (0 resource wait component), потому что ожидания ресурса не происходит (именно поэтому поток не попадает в список ожидания).
Ещё одна вещь, которую следует учитывать, — работает ли ваша рабочая нагрузка на виртуальной машине, которая испытывает задержки из-за переподписки хоста. Это может повысить количество ожиданий SOS_SCHEDULER_YIELD, как описано в этой статье.
Наконец, некоторые рабочие нагрузки могут страдать от ожиданий SOS_SCHEDULER_YIELD, когда включена автоматическая программная NUMA (soft-NUMA) — подробности см. в этой статье.
(Номера в списке соответствуют списку стеков вызовов ниже)
DROP DATABASE).(Номера в списке соответствуют номерам известных случаев)
SOS_Task::PostWait+90
SOS_Task::Sleep+147
IndexPageManager::GetNextPage+33b
IndexRowScanner::MoveKeyOrderToRowOnNextPage+16c
IndexRowScanner::MoveToRowOnNextPage+23b
IndexDataSetSession::GetNextRowValuesInternal+105b
RowsetNewSS::FetchNextRow+197
CQScanTableScanNew::GetRow+f2
CQScanXProducerNew::GetRowHelper+366
CQScanXProducerNew::GetRow+15
FnProducerOpen+57
FnProducerThread+851
SubprocEntrypoint+a59
SOS_Task::Param::Execute+21e
SOS_Scheduler::RunTask+a8SOS_Task::PostWait+90
SOS_Task::Sleep+147
YieldAndCheckForAbort+c3
lmAddCurToList+1d1
lmlink+12c7
soAllocRecBuf+328
RowsetSorted::InsertRow+2b97
RowsetChangeSort::InsertRow+19
CValRowNoHrow::SetDataX+48
CQScanSortNew::PushRow+34
CQScanSortNew::BuildSortTable+28f
CQScanSortNew::OpenHelper+c0
CQScanNLJoinNew::Open+24
CQScanNLJoinNew::Open+24
CQScanNLJoinNew::Open+24
CQScanNLJoinNew::Open+24
CQScanNew::OpenHelper+41
CQScanTopNew::Open+15
CQueryScan::StartupQuery+240
CXStmtQuery::SetupQueryScanAndExpression+2bd
CXStmtQuery::InitForExecute+34SOS_Task::PostWait+90
SOS_Task::Sleep+1b2
Worker::OSYieldNoAbort+2f
BPool::ReplenishFreeList+561
BPool::Steal+52f
BPool::NewPage+7af
PageRef::SetupPageHeaderPreAllocation+64
SetupPageHeaderPreAllocation+6c
TargetExtentMgr::AllocPageFromTargetExtent+5cd
AllocationReq::AllocateFromExistingExtents+9e1
AllocationReq::AllocatePages+15ca
AllocationReq::Allocate+f3
AllocateHoBtDataPage+5fd
IndexPageManager::AllocatePage+1b8
SplitPage+b59
IndexDataSetSession::InsertSmallRecord+1b5c
IndexDataSetSession::InsertRowInternal+2d11
DatasetSession::InsertRow+163
RowsetNewSS::InsertRow+26
CBlobHandleFactoryMain::CreateNewBlobHandleInternal+1ec
CBlobHandleFactoryMain::CreateNewBlobHandle+88
CBlobHandleHelper::CopyBlobHandleIntoTempOrInlined+1c5SOS_Task::PostWait+90
SOS_Task::Sleep+ea
YieldAndCheckForAbort+ec
BuildDensityMap+26
OptimizerUtil::CalculateDistinctCardUsingDensity+1da
OptimizerUtil::GroupCardDistinctHelper+8d2
CCostUtils::CalcLoopJoinCachedInfo+2036
CCostUtils::PcctxLoopJoinHelper+124
CTask_OptInputs::Perform+680
CMemo::ExecuteTasks+17c
CMemo::PerformOptimizationStage+347
CMemo::OptimizeQuery+9db
COptContext::PexprSearchPlan+131
COptContext::PcxteOptimizeQuery+24b8
COptContext::PqteOptimizeWrapper+221
PqoBuild+db6
CStmtQuery::InitQuery+27f
CStmtSelect::Init+ee
CCompPlan::FCompileStep+1844
CSQLSource::FCompile+13f7
CSQLSource::FCompWrapper+d3
CSQLSource::Transform+445SOS_Task::PostWait+90
SOS_Task::Sleep+1b2
Worker::OSYieldNoAbort+2f
BufIter::GetNext+100
BPool::RemoveDatabaseByFileId+c6
RecoveryUnit::Shutdown+14c
DBTABLE::Shutdown+179
DBMgr::ShutdownDB+1b1
NotifyEndDropDatabase::HandleEvent+69
XactRM::FireNotificationsInternal+cf
XactRM::SinglePhaseCommit+558
XactRM::CommitInternal+4b9
FullXactImp::Commit+326
CMsqlXactInternalReadWrite::Commit+15
CMsqlXactImp::Commit+1d2
CAutoMsqlXact::CommitNestedXact+bc
CStmtDropDB::XretExecute+bb1
CMsqlExecContext::ExecuteStmts<0,1>+864
CMsqlExecContext::FExecute+a48
CSQLSource::Execute+866Автор: 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 (т.е. без какого-либо простоя приложения).
Почему сервер при загрузке ЦП 40% может вести себя как при полностью утилизированных процессорах
Глубокое погружение в справедливость планировщика SOS, сборку мусора Hekaton, сканирование хэш-индексов и почему накопительное обновление CU5 для SQL Server имеет гораздо большее значение, чем думает большинство администраторов баз данных.
runnable_tasks_count часто опаснее, чем процент загрузки ЦП. Узнайте о типе ожидания SOS_SCHEDULER_YIELD в SQL Server: выявите причины, такие как конкуренция за ЦП, и найдите решения для настройки производительности с помощью экспертных советов. Этот тип ожидания возникает, когда задача добровольно уступает своё время ЦП, чтобы позволить другим задачам выполняться, что является естественной частью модели кооперативного планирования SQL Server. Однако, когда эти ожидания становятся частыми или продолжительными, они могут указывать на глубинные проблемы, ухудшающие производительность системы, что делает критически важным понимание их последствий.
По своей сути, SOS_SCHEDULER_YIELD отражает давление на ресурсы ЦП, поскольку задачи выстраиваются в очередь для выполнения. Хотя случайные уступки ожидаемы в загруженной среде, чрезмерные ожидания могут указывать на конкуренцию за ЦП, плохо оптимизированные запросы или даже аппаратные ограничения. Определение того, является ли этот тип ожидания симптомом более серьёзной проблемы, требует системного подхода к мониторингу и анализу, что в конечном итоге может привести к значительному повышению производительности.
В этой статье мы разберём тип ожидания SOS_SCHEDULER_YIELD, изучим его причины и то, когда он становится проблемой для вашей среды SQL Server. Мы проведём вас через методы диагностики, чтобы выявить корневые проблемы, и предоставим практические решения для снижения их влияния. Будь вы администратором баз данных (DBA) или разработчиком, понимание и устранение этого типа ожидания поможет обеспечить работу вашей базы данных на пике эффективности.
Вот интересный вопрос, который прислал мне мой друг Стив Джонс из SQL Server Central — будет ли один процессор с двумя ядрами работать лучше, чем два одноядерных процессора? Оба варианта имеют два вычислительных ядра, но аппаратная архитектура разная — какой из них обеспечит лучшую производительность SQL Server? Что ж, однозначного ответа нет — всё зависит от многих факторов! Я обсуждал эту тему с Джеромом Халмансом, бывшим коллегой по команде Storage Engine в SQL Server, и с его разрешения я основываю эту статью на нашем обсуждении.
В на Europe PASS Summit я читал доклад о диагностике памяти. В нём упомянул, что SQL Server будет использовать большие страницы (Large Pages), если включён trace flag 834. На конференции Кристиан Болтон, хорошо известный MVP из Великобритании, заметил, что видел в ERRORLOG сообщения о «large pages», хотя trace flag у него был выключен. Тогда я ответил, что не представляю, как такое возможно. Что ж, Кристиан, вы ничего не выдумали.
Вскоре тема всплыла снова, когда я помогал коллегам из CSS разбираться с тем же вопросом. Самое время углубиться и разобраться, что же там на самом деле происходит.
Автор оригинала: Kate Smith - Senior Program Manager SQL Server 2022
Степень параллелизма (degree of parallelism - DOP), с которой выполняется запрос, может сильно повлиять на его производительность. Когда для запроса используется параллелизм, уместен вопрос, используется ли для запроса оптимальный уровень параллелизма. Если степень параллелизма слишком высока, это может стать причиной снижения эффективности выполнения запроса. Если степень параллелизма слишком низкая, это может привести к потере возможного выигрыша во времени исполнения запроса, который мог получиться при большем параллелизме. Для запроса можно задать максимальную степень параллелизма вручную, указав его с помощью подсказки MAXDOP, установив его на уровне конфигурации сервера или пула регулятора ресурсов. Однако, часто бывает что пользователи подбирают степень параллелизма вручную для каждого критичного для приложений запроса. В лучшем случае используется подсказка MAXDOP, когда проблему удаётся локализовать, но чаще всего даже не пытаются определить оптимальную степень параллелизма для каждого запроса из рабочей нагрузки, а подбирается параметр конфигурации сервера max degree of parallelism (server configuration option).
Эта статья - вольная интерпретация рекомендаций: Microsoft, IBM, HP, Dell, QLogic, LSI, EMC, ACER, Bull, Fujitsu, Hitachi, NEC и Unisys. Некоторые рекомендуемые настройки требуют отдельного, обстоятельного разговора, и потому не включены в эту статью, а найти эти рекомендации можно в этом блоге.
Наиболее часто используемым способом изменения поведения SQL Server является выставление флагов трассировки. Следующие флаги трассировки поддерживаются в настоящее время Майкрософт для публикации результатов тесов производительности, таких как TPC-C. Если сотрудники Майкрософт рекомендуют Вам использовать другие флаги трассировки, которые не представлены в списке ниже, пожалуйста, сообщите об этом Джейми Редингу (Jamie.Reding@Microsoft.com) или Чарльзу Левину (Charles.Levine@Microsoft.com) до того, как вы опубликуете использование этих флагов.
Наиболее часто используемым
способом изменения поведения 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.
Рецензенты: 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.
Данная статья относится к
следующим версиям SQL Sever: 2008, 2008 R2, 2012 и 2014. Первый вариант статьи
был опубликован в 2011г.
Примечание: в данной статье
под количеством процессоров подразумеваются не сокеты, а представленные в
системе логические процессоры. Рекомендации статьи применимы в тех случаях,
когда для сервера баз данных доступно более восьми логических процессоров.
В зависимости от того, для каких нужд SQL Server использует память, дизайн ядра сервера баз данных предусматривает возможность секционирования распределения памяти. В процессе разработки SQL Server можно было выбирать схему секционирования исполнителя по процессорам, узлам или глобально. Некоторые связанные с распределением памяти функциональные модули SQL Server используют модуль распределения CMemPartitioned. Этот модуль секционирует память по процессорам или NUMA узлам, что может способствовать повышению параллелизма и производительности.
Автор: Боб Дорр – главный эскалационный инженер поддержки 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 . Автор допускает по тексту несколько вольную трактовку в описании алгоритмов, преследуя цель избавить статью от лишней официальности.
Тенденции развития аппаратных средств вычислительной техники оказывают влияние на то, как мы проектируем и разрабатываем программное обеспечение. Для сегодняшнего состояния рынка, персональные компьютеры с большим числом процессоров больше не редкость - это действительность.
Наличие таких возможностей как симметричная многопоточность (SMT), много-ядерные процессоры, слабо совместимые модели, память и процессоры с горячей заменой - становятся все более важны для достижения требуемых уровней производительности систем, их масштабируемости и администрирования. Есть две основные проблемы, связанные с проектированием программного обеспечения для современных аппаратных средств: недостаток хороших инструментов и неадекватный опыт разработчиков. Сервера базы данных пытаются использовать новые возможности серверных платформ, т.к. они стали доступны. Обычно сервер базы данных содержит встроенный уровень поддержки платформы, который скрывает от большинства разработчиков сервера базы данных специальные сообщения от аппаратных средств. SQL Server в предыдущих версиях имел довольно простой уровень поддержки платформы с ограниченной функциональностью. В SQL Server 2005 мы создали новый уровень поддержки платформы, который позволяет максимально задействовать параллелизм, секционирование и размещение. Этот уровень называется SQLOS. SQLOS - операционная система непривилегированного режима, которая встроена в иерархию дизайна сервера баз данных, точно также, как в эту иерархию входят аппаратные средства, на которых запускается сервер. Основные объекты SQLOS, это узлы, планировщики и задачи. SQLOS может подстраиваться и корректироваться под имеющуюся аппаратную конфигурацию сервера, на который он устанавливается. Это реализуется за счёт довольно сложного дизайна API, который позволяет разработчикам получать максимум преимуществ аппаратной платформы при написании программ, как на высоком, так и на низком уровне. Имеется встроенная поддержка размещения, параллелизма, и администрирования. SQLOS позволяет существенно поднять производительность и масштабируемости SQL Server 2005. В новой версии DBA получили возможность балансировать нагрузку SQL Server между компонентами имеющейся аппаратной конфигурации, в соответствии со своими бизнес задачами. В процессе разработки SQLOS мы получили очень много ценной информации и наметили ряд возможных усовершенствований на будущее.
По материалам статьи Slava Oks: SQL Server 2005 NUMA support & troubleshooting
SQL Server 2005 был разработан с учётом того, чтобы использовать в своей работе возможности и интерфейсы NUMA, которые поддерживаются современными серверными платформами и операционной системой Windows. Есть несколько проблем, о которых Вы должны знать при попытке запуска SQL Server на поддерживающих NUMA платформах.
В этой статье я хотел бы сделать обзор поддержки NUMA в Windows и SQL Server, описать их возможные конфигурации, и дать несколько советов относительно разрешения возможных проблем.
В последнем июньском SQL Server 2005 CTP реализовано большинство из необходимого для поддержки NUMA, так что Вы уже можете опробовать эти возможности и лично убедиться в том, как поддержка NUMA используется на практике. Если Вас больше интересует поиск и устранение проблем, без необходимости вникнуть в причины проблемы, Вы можете сразу перейти к разделу разрешения проблем в этой статье.
Уровень изложения материала: я ожидаю, что Вы имеете представление о классической архитектуре ccNUMA, и поэтому я не буду вдаваться в её подробности и объяснять её принципы.
По материалам статьи Slava Oks: Configuring SQL Server 2005 for Soft NUMA
Недавно, в статье http://blogs.msdn.com/slavao/articles/441058.aspx я рассмотрел вопросы обеспечения поддержки NUMA на программном уровне. На этой неделе один из наших клиентов столкнулся с интересной проблемой. Клиенту необходимо было балансировать загрузку процессоров в рамках одного экземпляра SQL Server. Приложение клиента было гетерогенным. Часть запросов этого приложения была схожа с запросами эталонного теста TPCH, а другая часть предназначена для загрузки данных. В распоряжении клиента имеется NUMA система, с 2 узлами по четыре процессора в каждом. Клиент хотел оставить под загрузку данных два процессора, а остальные процессоры предоставить для исполнения запросов. Возможно ли это реализовать?
По материалам статьи Slava Oks: Be Aware: Using AWE, locked pages in memory, on 64 bit
Мы уже говорили о механизме Windows AWE на 32-х битной платформе и как SQL Server его использует. Сегодня я хотел бы пробежаться по AWE и связанным с ним механизмам на 64-х битной платформе.
Многие наверняка удивлены тем, что механизм AWE здесь все еще используется и оказывается полезным и на 64-х битных платформах. Вы уже знаете, что этот механизм состоит из двух частей, распределяющих физическую память и отображающую её на VAS данного процесса. Преимущество механизма распределения состоит в том, что если физическая память распределена, то операционная система уже не сможет её затребовать, пока использующий её процесс не будет завершён или это процесс освободит память, вернув её операционной системе. С помощью такого подхода приложение может управлять и даже полностью предотвращать листание. Преимущество механизма mapping/unmapping в том, что одна и та же физическая страница может быть отображена на разные участки VAS. Как Вы догадываетесь, на 64-х битных платформах в unmapping нет необходимости, поскольку VAS мы имеем достаточно, чтобы вместить всю имеющуюся физическую память.