Руководство по архитектуре потоков и задач

Область применения: SQL Server База данных SQL Azure Управляемый экземпляр SQL Azure

Планирование задач операционной системы

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

Когда операционная система выполняет экземпляр приложения, она создает модуль, называемый процессом, для управления экземпляром. Процесс имеет поток выполнения. Это ряд программных команд, выполненных кодом приложения. Например, если простое приложение содержит один набор инструкций, которые можно выполнить последовательно, этот набор инструкций обрабатывается как одна задача и существует только один путь выполнения (или поток) приложения. Более сложные приложения могут иметь несколько задач, которые могут выполняться одновременно, а не последовательно. Для этого приложение может запустить для каждой задачи отдельные процессы, которые являются ресурсоемкими, или запустить отдельные потоки, которые являются относительно менее ресурсоемкими. Кроме этого, каждый поток можно запланировать для выполнения независимо от других потоков, связанных с процессом.

Потоки позволяют сложным приложениям более эффективно использовать ЦП, даже на компьютерах с одним ЦП. С одним ЦП только один поток может выполняться одновременно. Если один поток выполняет долго выполняющуюся операцию, которая не использует ЦП, например чтение или запись диска, другой поток может выполняться до завершения первой операции. Возможность выполнять потоки, в то время как другие потоки ожидают завершения операции, позволяет приложению увеличить использование ЦП. Это особенно касается многопользовательских приложений, интенсивно использующих операции дискового ввода-вывода, например сервера базы данных. Компьютеры с несколькими ЦП могут одновременно выполнять один поток для каждого ЦП. Например, если компьютер имеет восемь ЦП, он может выполнять одновременно восемь потоков.

Планирование задач SQL Server

В области SQL Server запрос является логическим представлением запроса или пакета. Запрос также представляет операции, необходимые системным потокам, таким как контрольная точка или модуль записи журнала. Запросы существуют в различных состояниях в течение всего времени существования и могут накапливать ожидания, когда ресурсы, необходимые для выполнения запроса, недоступны, например блокировки или блокировки. Дополнительные сведения о состояниях запросов см. в статье sys.dm_exec_requests (Transact-SQL).

Задачи

Задача представляет единицу работы, которую необходимо завершить для выполнения запроса. Одному запросу можно назначить одну или несколько задач.

• Параллельные запросы имеют несколько активных задач, выполняемых одновременно, а не последовательно, с одной родительской задачей (или координирующей задачей) и несколькими дочерними задачами. План выполнения для параллельного запроса может иметь последовательные ветви — области плана с операторами, которые не выполняются параллельно. Родительская задача отвечает и за выполнение этих последовательных операторов.
• Последовательные запросы имеют только одну активную задачу в любой момент времени во время выполнения. Задачи находятся в различных состояниях в течение всего времени существования. Дополнительные сведения о состояниях задач см. в статье sys.dm_os_tasks (Transact-SQL). Задачи в приостановленном состоянии ожидают ресурсов, необходимых для выполнения задачи. До того времени они недоступны. Дополнительные сведения об ожидающих задачах см. в разделе sys.dm_os_waiting_tasks.

Работники

Рабочий поток SQL Server, также известный как рабочий или поток, является логическим представлением потока операционной системы. При выполнении последовательных запросов SQL Server ядро СУБД создает рабочую роль для выполнения активной задачи (1:1). При выполнении параллельных запросов в режиме строки SQL Server ядро СУБД назначает рабочую роль для координации дочерних работников, ответственных за выполнение задач, назначенных им (также 1:1), называемых родительским потоком (или координирующим потоком). Родительский поток имеет связанную с ним родительскую задачу. Родительский поток — это точка входа запроса, и она существует даже до того, как ядро начало анализировать запрос. Основные задачи родительского потока:

• Координирование параллельного сканирования.
• Запуск параллельных дочерних работников.
• Сбор строк из параллельных потоков и их отправка клиенту.
• Выполнение локальных и глобальных операций агрегирования.

Количество рабочих потоков, порожденных для каждой задачи, зависит от следующих факторов:

• Имеет ли запрос право на параллелизм, что определяется оптимизатором запросов.

• Какова фактическая степень параллелизма (DOP) в системе на основе текущей нагрузки. Она может отличаться от предполагаемой степени параллелизма, оценка которой выполняется на основе конфигурации сервера для максимальной степени параллелизма (MAXDOP). Например, конфигурация сервера для MAXDOP может составлять 8, но доступное значение DOP в среде выполнения может составлять только 2, что влияет на производительность запросов. Давление на память и отсутствие рабочих ролей — это два условия, которые снижают доступность DOP во время выполнения.

Планировщики задач

Планировщик, также известный как планировщик SOS, управляет рабочими потоками, требующими времени обработки для выполнения работы от имени задач. Каждый планировщик сопоставляется с отдельным процессором (ЦП). Время, в течение которого рабочая роль может оставаться активной в планировщике, называется квантом времени операционной системы (не более 4 мс). По истечении кванта времени рабочая роль передает время другим рабочим ролям, которым требуется доступ к ресурсам ЦП, и изменяет свое состояние. Это сотрудничество между рабочими ролями для повышения уровня доступа к ресурсам ЦП называется совместное планирование, также известное как планирование в режиме без вытеснения. В свою очередь, изменение состояния рабочей роли распространяется на задачу, связанную с этой рабочей ролью, и на запрос, связанный с задачей. Дополнительные сведения о состояниях рабочих ролей см. в статье sys.dm_os_workers (Transact-SQL). Дополнительные сведения о планировщиках см. в sys.dm_os_schedulers.

Таким образом, запрос может порождать одну или несколько задач для выполнения единиц работы. Каждая задача назначается рабочему потоку, который отвечает за выполнение этой задачи. Каждый рабочий поток должен быть запланирован (помещен в планировщик) для активного выполнения задачи.

Рассмотрим следующий сценарий:

• Рабочая роль 1 — это длительно выполняемая задача, например запрос на чтение с упреждающим чтением таблиц на основе дисков. Рабочая роль 1 находит необходимые страницы данных в буферном пуле, поэтому она не должна ждать операций ввода-вывода и может использовать полный квант времени до приостановки.
• Рабочая роль 2 выполняет более кратковременные задачи на уровне долей миллисекунд и поэтому должна ожидать исчерпания своего полного кванта времени.

В этом сценарии и до SQL Server 2014 (12.x), рабочая роль 1 позволяет в основном монополизировать планировщика, имея более общее квантовое время.

Начиная с SQL Server 2016 (13.x), совместное планирование включает планирование большого дефицита (LDF). Планирование LDF позволяет отслеживать модели использования квантов, при этом планировщик не используется монопольно ни одним рабочим потоком. В том же сценарии рабочая роль 2 допускает использование повторяющихся квантовых ролей до того, как рабочая роль 1 допускает больше квантовых вычислений, поэтому не позволяет рабочей роли 1 монополизировать планировщика в неуправляемом шаблоне.

Расписание параллельных задач

Представьте, что SQL Server настроен с помощью MaxDOP 8, а сопоставление ЦП настроено для 24 ЦП (планировщиков) на узлах NUMA 0 и 1. Планировщики с 0 по 11 относятся к узлу NUMA 0, планировщики с 12 по 23 относятся к узлу NUMA 1. Приложение отправляет следующий запрос (запрос) в ядро СУБД:

SELECT h.SalesOrderID,
    h.OrderDate,
    h.DueDate,
    h.ShipDate
FROM Sales.SalesOrderHeaderBulk AS h
INNER JOIN Sales.SalesOrderDetailBulk AS d
    ON h.SalesOrderID = d.SalesOrderID
WHERE (h.OrderDate >= '2014-3-28 00:00:00');

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

Хотя в этом плане выполнения есть три ветви, в любой момент выполнения в этом плане могут одновременно выполняться только две ветви.

1. Ветвь, в которой сканирование кластеризованного индекса используется в Sales.SalesOrderHeaderBulk (во входных данных сборки соединения), выполняется отдельно.
2. Ветвь, в которой сканирование кластеризованного индекса используется в Sales.SalesOrderDetailBulk (во входных данных пробы соединения), выполняется параллельно с ветвью, в которой был создан объект Bitmap и сейчас выполняется оператор Hash Match.

Showplan XML показывает, что в узле NUMA 0 было зарезервировано и использовано 16 рабочих потоков:

<ThreadStat Branches="2" UsedThreads="16">
  <ThreadReservation NodeId="0" ReservedThreads="16" />
</ThreadStat>

Резервирование потоков гарантирует, что ядро СУБД имеет достаточно рабочих потоков для выполнения всех задач, необходимых для запроса. Потоки могут быть зарезервированы на нескольких узлах NUMA или только на одном. Резервирование потока происходит во время выполнения до начала выполнения и зависит от нагрузки планировщика. Число зарезервированных рабочих потоков является универсальным производным от формулы concurrent branches * runtime DOP и исключает родительский рабочий поток. Количество рабочих потоков в каждой ветви ограничено значением MaxDOP. В этом примере имеется два параллельных ветвя, поэтому MaxDOP имеет значение 8.2 * 8 = 16

Для справки просмотрите динамический план выполнения из динамической статистики запросов, где одна ветвь завершила выполнение и две ветви выполняются параллельно.

SQL Server ядро СУБД назначает рабочий поток для выполнения активной задачи (1:1), которая может наблюдаться во время выполнения запроса путем запроса sys.dm_os_tasks dmV, как показано в следующем примере:

SELECT parent_task_address, task_address,
       task_state, scheduler_id, worker_address
FROM sys.dm_os_tasks
WHERE session_id = <insert_session_id>
ORDER BY parent_task_address, scheduler_id;

Вот результирующий набор. Обратите внимание, что существует 17 активных задач для ветвей, выполняемых в настоящее время: 16 дочерних задач, соответствующих зарезервированным потокам, а также родительской задачи или координации задачи.

Обратите внимание, что всем 16 дочерним задачам назначены разные рабочие потоки (их можно увидеть в столбце worker_address), но все рабочие роли назначены одному и тому же пулу из восьми планировщиков (0, 5, 6, 7, 8, 9, 10, 11), а родительская задача назначена планировщику, не входящему в этот пул (3).

Рабочий поток может оставаться активным только в планировщике во время его квантовой (4 мс) и должен получить планировщик после того, как этот квантовый поток истек, чтобы рабочий поток, назначенный другой задаче, мог стать активным. Когда срок действия квантовой функции рабочей роли истекает и больше не активен, соответствующая задача помещается в очередь FIFO в состоянии RUNNABLE, пока она не перейдет в состояние RUNNABLE, если задача не требует доступа к ресурсам, недоступным в данный момент, например блокировка или блокировка, в этом случае задача будет помещена в состояние SUSPENDED вместо RUNNABLE, до тех пор, пока эти ресурсы не будут доступны.

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

Выделение потоков на ЦП

По умолчанию каждый экземпляр SQL Server запускает каждый поток, а операционная система распределяет потоки из экземпляров SQL Server среди процессоров (ЦП) на компьютере на основе нагрузки. Если сходство процессов включено на уровне операционной системы, операционная система назначает каждый поток конкретному ЦП. В отличие от этого, SQL Server ядро СУБД назначает рабочие потоки SQL Server планировщикам, которые равномерно распределяют потоки между ЦП, в циклически переборе.

Для обеспечения многозадачности, например, когда несколько приложений используют один и тот же набор ЦП, операционная система иногда распределяет рабочие потоки между разными ЦП. Хотя с точки зрения операционной системы эти действия эффективны, они могут снизить производительность SQL Server при больших системных нагрузках, так как данные кеша каждого процессора будут постоянно обновляться. В этих условиях назначение ЦП определенных потоков может повысить производительность, устраняя повторную загрузку процессоров и уменьшая количество переносов потоков между ЦП (а значит, уменьшая число переключений контекста). Такая связь между потоком и процессором называется соответствием процессоров. Если функция подобия была включена, операционная система назначает поток конкретному ЦП.

Параметр affinity mask задается с помощью инструкции ALTER SERVER CONFIGURATION. Если маска сходства не задана, экземпляр SQL Server выделяет рабочие потоки равномерно среди планировщиков, которые не были отключены.

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

Использование параметра упрощенного пула

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

• установлен производительный многопроцессорный сервер;
• все процессоры работают почти на пределе производительности;
• высок уровень переключения контекста.

В таких системах может наблюдаться небольшое повышение эффективности, если для параметра "Использование упрощенных пулов" установлено значение 1.

Выполнение потоков и волокон

В Microsoft Windows используется числовая система приоритетов, распределяющая выполняемые потоки по уровням от 1 до 31. Значение 0 зарезервировано для использования операционной системой. При наличии в очереди на выполнение нескольких потоков Windows сначала обслуживает поток с наивысшим приоритетом.

Каждый экземпляр SQL Server по умолчанию имеет уровень приоритета 7, что соответствует стандартному уровню. Это значение по умолчанию задает потокам SQL Server достаточно высокий уровень приоритета, позволяющий им получать достаточно ресурсов ЦП, не снижая производительность других приложений.

Параметр конфигурации priority boost используется для повышения приоритета потоков экземпляра SQL Server до значения 13. Это наивысший приоритет. Этот параметр назначает потокам SQL Server более высокий приоритет по отношению к другим приложениям. Таким образом, потоки SQL Server, как правило, будут отправляться всякий раз, когда они готовы к выполнению и не преумножены потоками из других приложений. Это, возможно, поможет повысить производительность сервера, на котором выполняются только экземпляры SQL Server. Однако если операция с интенсивным объемом памяти происходит в SQL Server, однако другие приложения, скорее всего, не имеют достаточного приоритета, чтобы упредить поток SQL Server.

Если на компьютере выполняется несколько экземпляров SQL Server, повышение приоритетов одних может привести к снижению производительности других. Кроме того, включение параметра priority boost может привести к простою других приложений и компонентов, выполняемых на компьютере. Таким образом, данный параметр рекомендуется использовать только в строго определенных условиях.

ЦП с поддержкой горячей замены

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

Требования для ЦП с поддержкой горячей замены:

• оборудование с поддержкой ЦП с поддержкой горячей замены;
• Требуется поддерживаемая версия Windows Server Datacenter или Enterprise. Начиная с Windows Server 2012, горячее добавление поддерживается в выпуске Standard.
• Требуется выпуск SQL Server Enterprise.
• SQL Server нельзя настроить для использования обратимого NUMA. Дополнительные сведения о программной архитектуре NUMA см. в разделе Архитектура Soft-NUMA (SQL Server).

SQL Server не использует автоматически ЦП после их добавления. Благодаря этому SQL Server не использует ЦП, добавленные для каких-либо других целей. Добавив ЦП, выполните инструкцию RECONFIGURE . Так SQL Server будет распознавать новые ЦП в качестве доступных ресурсов.

Рекомендации по запуску SQL Server на компьютерах с более чем 64 ЦП

Назначение аппаратных потоков ЦП

Не используйте маску сходства и параметры конфигурации сервера affinity64 для привязки процессоров к определенным потокам. Эти параметры ограничены 64 процессорами. Вместо этого следует использовать параметр SET PROCESS AFFINITY инструкции ALTER SERVER CONFIGURATION.

Управление размером файла журнала транзакций

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

Установка максимальной степени параллелизма для операций с индексами

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

Помимо настройки параметра конфигурации сервера max degree of parallelism (MAXDOP), рассмотрите возможность настройки параллелизма для операций с индексами с помощью параметра MAXDOP. Дополнительные сведения см. в статье Настройка параллельных операций с индексами. Дополнительные сведения и рекомендации по настройке параметра конфигурации сервера с максимальной степенью параллелизма см. в разделе "Настройка параметра конфигурации сервера максимального уровня параллелизма".

Максимальное количество рабочих потоков

SQL Server динамически настраивает параметр конфигурации сервера максимальных рабочих потоков при запуске. SQL Server использует количество доступных ЦП и системную архитектуру для определения конфигурации сервера во время запуска с помощью документированного формулы.

Это расширенный параметр, и изменять его следует только опытным администраторам баз данных или сертифицированным по SQL Server специалистам. Если вы считаете, что есть проблема с производительностью, вероятно, причина не в доступности рабочих потоков. Скорее всего, их ожидание вызвано чем-то наподобие операций ввода-вывода. Рекомендуется найти причину проблемы производительности, прежде чем изменять параметр max worker threads. Тем не менее, если необходимо вручную задать максимальное число рабочих потоков, это значение конфигурации всегда должно быть в семь раз больше числа ЦП, имеющихся в системе. Дополнительные сведения см. в статье Настройка параметра max worker threads.

Избегайте использования трассировки SQL и профилировщика SQL Server

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

Установка количества tempdb файлов данных

Количество файлов зависит от числа (логических) процессоров на компьютере. Как правило, если число логических процессоров меньше или равно восьми, используйте равное ему число файлов данных. Если число логических процессоров больше восьми, используйте восемь файлов данных, а затем, если состязание сохраняется, увеличивайте число файлов данных на значение, кратное 4, пока состязание не уменьшится до приемлемого уровня, или внесите изменения в рабочую нагрузку или код. Кроме того, помните о других рекомендациях, tempdbдоступных в оптимизации производительности tempdb в SQL Server.

Однако тщательно учитывая потребности tempdbпараллелизма, вы можете сократить затраты на управление базами данных. Например, если в системе используется 64 ЦП и обычно используется tempdbтолько 32 запроса, увеличение числа tempdb файлов до 64 не улучшит производительность.

Компоненты SQL Server, которые поддерживают более 64 ЦП

В следующей таблице перечислены компоненты SQL Server и указано, могут ли они использовать больше чем 64 ЦП.