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

Менеджер памяти SQLOS: диагностика вытеснения памяти

По материалам статьи Slava Oks: SQLOS's memory manager: responding to memory pressure

При настройке SQL Server очень важно понимать, как он реагирует на вытеснение памяти. Я уже посветил довольно много времени описанию разных типов вытеснения памяти. В этой статье Вы узнаете, почему это так важно. Вытеснение памяти можно классифицировать двумя основными группами: вытеснение VAS и вытеснение физической памяти. Вытеснение физической памяти может быть спровоцировано операционной системой, мы назвали его внешним, или оно может быть спровоцировано процессом, такое вытеснение мы называем внутренним.
SQLOS использует специализированную структуру, которая занимается обслуживанием любого из типов вытеснения памяти процесса. В основе этой структуры находится Resource Monitor (RM). RM контролирует состояние внешних и внутренних индикаторов памяти. Когда один из них изменяется, RM отслеживает состояние всех индикаторов. При этом соответствующее оповещение отображает состояние индикатора. Такое оповещение рассчитано на то, что оно будет разослано всем клеркам памяти (Memory Clerks).

Контроль VAS в SQL Server 2005, продолжение…

По материалам статьи Slava Oks: Tracking VAS in Yukon, cont...

Некоторые из Вас, возможно, скучали, читая мою предыдущую статью "Обзор Virtual Address Space - VAS". Я понимаю, что тема VAS до этого была многократно освещена множеством авторов и ей было уделено много времени, и Вы наверняка знаете об этом больше, чем даже хотелось бы знать. Однако, наберитесь, пожалуйста, терпения. Я хочу дать достаточный предварительный обзор темы, что бы читатель смог легко ориентироваться в предлагаемом ему материале. Мне хотелось бы показать ту часть внутренней организации операционной системы, без которой будет сложно охватить тему, о которой Вы хотите узнать побольше: "Управление памятью в SQL Server". Поэтому я продолжу эту тему в следующий раз.

Обзор Virtual Address Space - VAS

По материалам статьи Slava Oks: A look at Virtual Address Space - VAS

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

Контроль VAS в SQL Server

По материалам статьи Slava Oks: Tracking VAS in Yukon

Когда разработчики приступили к работе над следующей версией SQL Server - Yukon, они осознавали, что развитые средства поддержки являются одним из ключевых моментов успешности проекта. Своей целью автор ставит охват тем, описывающих "нижние" уровни организации СУБД, которые многим из Вас, как он уверен, действительно интересны, то есть это управление памятью и планирование ресурсов. В этой статье представлен беглый обзор того, как можно контролировать и диагностировать виртуальное адресное пространство - Virtual Address Space (VAS), используемое SQL Server. Автор надеется, что Вы понимаете что такое VAS и как оно организовано в Windows. Надеясь на Ваше терпение, автор постарается побыстрее описать всю исходную информацию, что бы в ближайшем будущем мы могли подробно поговорить о менеджере памяти SQL Server.
Представленный ниже запрос можно выполнять на сервере периодически, чтобы отслеживать возможные отклонения, связанные с VAS. Постоянное отклонение VAS от нормы может указывать на потенциальную проблему. Не смотря на то, что Yukon умет восстанавливаться после вытеснения VAS намного лучше, чем SQL Server 2000, если в реальности существует утечка памяти, спровоцированная внешними компонентами загруженными в наше VAS, поделать с этим будет практически ничего нельзя...