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

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

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

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

Автор: 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, и с его разрешения я основываю эту статью на нашем обсуждении.

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

Новое в 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).

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

Флаги трассировки для эталонного теста производительности 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.

Пример настройки 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.

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 узлам, что может способствовать повышению параллелизма и производительности.

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 . Автор допускает по тексту несколько вольную трактовку в описании алгоритмов, преследуя цель избавить статью от лишней официальности.

Новшества SQL Server 2005 для поддержки современных серверных платформ

По материалам статьи Slava Oks: A new platform layer in SQL Server 2005 to exploit new hardware capabilities and their trends

Тенденции развития аппаратных средств вычислительной техники оказывают влияние на то, как мы проектируем и разрабатываем программное обеспечение. Для сегодняшнего состояния рынка, персональные компьютеры с большим числом процессоров больше не редкость - это действительность.
Наличие таких возможностей как симметричная многопоточность (SMT), много-ядерные процессоры, слабо совместимые модели, память и процессоры с горячей заменой - становятся все более важны для достижения требуемых уровней производительности систем, их масштабируемости и администрирования. Есть две основные проблемы, связанные с проектированием программного обеспечения для современных аппаратных средств: недостаток хороших инструментов и неадекватный опыт разработчиков. Сервера базы данных пытаются использовать новые возможности серверных платформ, т.к. они стали доступны. Обычно сервер базы данных содержит встроенный уровень поддержки платформы, который скрывает от большинства разработчиков сервера базы данных специальные сообщения от аппаратных средств. SQL Server в предыдущих версиях имел довольно простой уровень поддержки платформы с ограниченной функциональностью. В SQL Server 2005 мы создали новый уровень поддержки платформы, который позволяет максимально задействовать параллелизм, секционирование и размещение. Этот уровень называется SQLOS. SQLOS - операционная система непривилегированного режима, которая встроена в иерархию дизайна сервера баз данных, точно также, как в эту иерархию входят аппаратные средства, на которых запускается сервер. Основные объекты SQLOS, это узлы, планировщики и задачи. SQLOS может подстраиваться и корректироваться под имеющуюся аппаратную конфигурацию сервера, на который он устанавливается. Это реализуется за счёт довольно сложного дизайна API, который позволяет разработчикам получать максимум преимуществ аппаратной платформы при написании программ, как на высоком, так и на низком уровне. Имеется встроенная поддержка размещения, параллелизма, и администрирования. SQLOS позволяет существенно поднять производительность и масштабируемости SQL Server 2005. В новой версии DBA получили возможность балансировать нагрузку SQL Server между компонентами имеющейся аппаратной конфигурации, в соответствии со своими бизнес задачами. В процессе разработки SQLOS мы получили очень много ценной информации и наметили ряд возможных усовершенствований на будущее.

Поддержка и разрешение проблем процессорной архитектуры NUMA в SQL Server 2005

По материалам статьи 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, и поэтому я не буду вдаваться в её подробности и объяснять её принципы.

Тюнинг SQL Server 2005 для программной поддержки NUMA

По материалам статьи Slava Oks: Configuring SQL Server 2005 for Soft NUMA

Недавно, в статье http://blogs.msdn.com/slavao/articles/441058.aspx я рассмотрел вопросы обеспечения поддержки NUMA на программном уровне. На этой неделе один из наших клиентов столкнулся с интересной проблемой. Клиенту необходимо было балансировать загрузку процессоров в рамках одного экземпляра SQL Server. Приложение клиента было гетерогенным. Часть запросов этого приложения была схожа с запросами эталонного теста TPCH, а другая часть предназначена для загрузки данных. В распоряжении клиента имеется NUMA система, с 2 узлами по четыре процессора в каждом. Клиент хотел оставить под загрузку данных два процессора, а остальные процессоры предоставить для исполнения запросов. Возможно ли это реализовать?

AWE и locked pages in memory на 64-х битной платформе

По материалам статьи 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 мы имеем достаточно, чтобы вместить всю имеющуюся физическую память.

Размер стека IA64

По материалам статьи Slava Oks: Be Aware: IA64 Stack Size

Тема стека в операционной системе Windows всегда вызывает интерес. С ней связано много интересных технических проблем. В какие-то моменты Вы думаете, что полностью понимаете всё о стеке, но потом внезапно обнаруживаете ещё одну тайну.

Кэширование в SQLOS

 По материалам статьи Slava Oks: SQLOS Caching

Эта статья рассказывает о том, как изменился механизм кэширования в SQL Server 2005.

Отличия в кэшировании SQL Server 2000 и SQL Server 2005

Управление памятью SQL Server 2005 отличается от SQL Server 2000 более сложной структурой кэширования. В SQL Server 2000 реализовано два основных кэша: кэш страницы данных, называемый Buffer Pool, и кэш процедур, кэш планов исполнения запросов. Buffer Pool и кэш процедур очень сильной связаны между собой. Например, кэш процедур использует механизм выселения буферного пула, чтобы управлять его размером, не смотря на то, что оба кэша имеют собственные политики оценки. Использование связанных BP и кэша процедур значительно упрощает механизм кэширования SQL Server 2000, с которым мы, как правило, имеем дело при разрешении проблем.
Эта модель очень хорошо работала в SQL Server 2000, но она непригодна для SQL Server 2005. С появлением в SQL Server 2005 новых функциональных возможностей и новых требований, появилась необходимость увеличения числа кэшей. Связь всех кэшей с Buffer Pool стала не только проблематичной, но даже и невыполнимой. Стало очевидно, что мы должны создать общую структуру кэширования. Ключевой идеей этой структуры является однородный механизм и общая политика оценки.

Обзор механизмов виртуальной памяти Windows (продолжение "Обзор Virtual Address Space")

 По материалам статьи Slava Oks: A look at Windows Virtual Memory mechanisms (continuation of "A look at Virtual Address Space - VAS")

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