Настройка максимальных рабочих потоков (параметр конфигурации сервера)
Применимо к:
SQL Server
В этой статье описывается настройка параметра конфигурации сервера максимального числа рабочих потоков в SQL Server с помощью SQL Server Management Studio или Transact-SQL. Параметр max worker threads настраивает количество рабочих потоков, доступных в SQL Server для обработки запросов запросов, входа, выхода и аналогичных запросов приложений.
SQL Server использует собственные потоковые службы операционных систем для обеспечения следующих условий:
Одна или несколько потоков одновременно поддерживают каждую сеть, поддерживаемую SQL Server.
Один поток обрабатывает контрольные точки базы данных.
Пул потоков обрабатывает запросы от всех пользователей.
Значение по умолчанию для параметра max worker threads — 0. Это позволяет SQL Server автоматически настраивать количество рабочих потоков при запуске. Настройка по умолчанию является оптимальной для большинства систем. Но иногда, в зависимости от конфигурации системы, установка параметра max worker threads в другое определенное значение может улучшить производительность.
Ограничения
Если реальное количество запросов превышает число, заданное параметром max worker threads, то SQL Server создает пул рабочих потоков, чтобы передавать запросы на обработку освободившимся рабочим потокам. Рабочий поток назначается только активным запросам и освобождается после обслуживания запроса. Это происходит в случае, даже если сеанс пользователя или подключение, в которых был создан запрос, остаются открытыми.
Параметр конфигурации сервера максимальных рабочих потоков не ограничивает все потоки, которые могут быть сложены внутри подсистемы. Системные потоки, требуемые для LazyWriter, контрольной точки, модуля записи журнала, Service Broker, диспетчера блокировок или других задач, порождаются независимо от этого ограничения. Группы доступности используют некоторые рабочие потоки из максимального ограничения рабочих потоков, но также используют системные потоки (см . раздел "Использование потоков по группам доступности") Если превышено количество потоков, настроенных, следующий запрос содержит сведения о системных задачах, которые породили дополнительные потоки.
SELECT s.session_id, r.command, r.status, r.wait_type, r.scheduler_id, w.worker_address, w.is_preemptive, w.state, t.task_state, t.session_id, t.exec_context_id, t.request_id FROM sys.dm_exec_sessions AS s INNER JOIN sys.dm_exec_requests AS r ON s.session_id = r.session_id INNER JOIN sys.dm_os_tasks AS t ON r.task_address = t.task_address INNER JOIN sys.dm_os_workers AS w ON t.worker_address = w.worker_address WHERE s.is_user_process = 0;
Рекомендации
Это расширенный параметр, и изменять его следует только опытным администраторам баз данных или сертифицированным по SQL Server специалистам. Если вы считаете, что есть проблема с производительностью, вероятно, причина не в доступности рабочих потоков. Причина, скорее всего, связана с действиями, которые занимают рабочие потоки и не освобождают их. В число примеров входят длительные запросы или узкие места в системе (операции ввода-вывода, блокировка, ожидания кратковременной блокировки, ожидания сетевых операций). Рекомендуется найти причину проблемы производительности, прежде чем изменять параметр max worker threads. Дополнительные сведения об оценке производительности см. в статье Наблюдение и настройка производительности.
Пул потоков помогает оптимизировать производительность при подключении к серверу большого числа клиентов. Обычно для каждого запроса в операционной системе создается отдельный поток. Однако в случае сотен соединений с сервером, использование одного потока на каждый запрос приводит к потреблению большого числа системных ресурсов. Параметр "Максимальное количество рабочих потоков" позволяет SQL Server создавать пул рабочих потоков для обслуживания большего количества запросов, что повышает производительность.
В следующей таблице показано автоматически настроенное число максимальных рабочих потоков (если задано значение 0), на основе различных сочетаний логических ЦП, архитектуры компьютера и версий SQL Server с помощью формулы: Max Workers + ((логические ЦП - 4) * Рабочие нагрузки на ЦП).<
Число логических ЦП 32-разрядный компьютер (до SQL Server 2014 (12.x)) 64-разрядный компьютер (до SQL Server 2016 (13.x) с пакетом обновления 1 (SP1) 64-разрядный компьютер (начиная с SQL Server 2016 (13.x) с пакетом обновления 2 (SP2) и SQL Server 2017 (14.x)) <=4 256 512 512 8 288 576 576 16 352 704 704 32 480 960 960 64 736 1472 1472 128 1248 2496 4480 256 2272 4544 8576 До SQL Server 2016 (13.x) с пакетом обновления 1 (SP1 ), рабочие нагрузки на ЦП зависят только от архитектуры (32-разрядная или 64-разрядная):
Число логических ЦП 32-разрядный компьютер 1 64-разрядный компьютер <=4 256 512 > 4 256 + ((логические ЦП - 4) * 8) 512 2 + ((логические ЦП - 4) * 16) Начиная с SQL Server 2016 (13.x) с пакетом обновления 2 (SP2) и SQL Server 2017 (14.x), рабочие нагрузки на ЦП зависят от архитектуры и количества процессоров (от 4 до 64 или более 64):
Число логических ЦП 32-разрядный компьютер 1 64-разрядный компьютер <=4 256 512 > 4 и < = 64 256 + ((логические ЦП - 4) * 8) 512 2 + ((логические ЦП - 4) * 16) > 64 256 + ((логические ЦП - 4) * 32) 512 2 + (логические ЦП - 4) * 32) 1 Начиная с SQL Server 2016 (13.x), SQL Server больше не может быть установлен в 32-разрядной операционной системе. 32-разрядные значения компьютера перечислены для помощи клиентам, работающим под управлением SQL Server 2014 (12.x) и более ранних версий. Рекомендуется использовать 1024 в качестве максимального числа рабочих потоков для экземпляра SQL Server, работающего на 32-разрядном компьютере.
2 Начиная с SQL Server 2017 (14.x), значение максимального числа рабочих ролей по умолчанию делится на 2 для компьютеров с менее чем 2 ГБ памяти.
Совет
Дополнительные сведения об использовании более 64 логических ЦП см. в рекомендациях по запуску SQL Server на компьютерах с более чем 64 ЦП.
Если все рабочие потоки активны с длительными запросами, SQL Server может не отвечать, пока рабочий поток не завершится и станет доступным. Хотя это не дефект, иногда это может быть нежелательным. Если процесс, как представляется, не отвечает, и новые запросы не могут обрабатываться, подключитесь к SQL Server с помощью выделенного подключения администратора (DAC) и убьете этот процесс. Во избежание этого увеличьте максимальное число потоков управления.
Разрешения
sp_configure Разрешения на выполнение без параметров или только с первым параметром предоставляются всем пользователям по умолчанию. Чтобы выполнить sp_configure оба параметра для изменения параметра конфигурации или запуска RECONFIGURE инструкции, пользователю необходимо предоставить ALTER SETTINGS разрешение на уровне сервера. Разрешение ALTER SETTINGS неявным образом предоставлено предопределенным ролям сервера sysadmin и serveradmin.
Использование SQL Server Management Studio (SSMS)
В обозревателе объектов щелкните правой кнопкой мыши сервер и выберите пункт Свойства.
Выберите узел процессоров.
В поле Максимальное число рабочих потоков введите или выберите значение от 128 до 65 535.
Совет
Используйте параметр максимальной рабочей роли для настройки количества рабочих потоков , доступных для процессов SQL Server. Значение по умолчанию параметра max worker threads является оптимальным для большинства систем.
Но в зависимости от конфигурации системы установка параметра max worker threads в меньшее значение может улучшить производительность.
Дополнительные сведения см. в разделе Рекомендации этой статьи.
Использование Transact-SQL
Соединитесь с ядром СУБД .
На стандартной панели выберите пункт Создать запрос.
Скопируйте приведенный ниже пример в окно запроса и нажмите кнопку Выполнить. В этом примере описывается использование процедуры sp_configure для задания значения параметра
max worker threadsравным900.
EXEC sp_configure 'show advanced options', 1;
GO
RECONFIGURE;
GO
EXEC sp_configure 'max worker threads', 900;
GO
RECONFIGURE;
GO
Изменение вступит в силу сразу после выполнения RECONFIGURE, не требуя перезапуска ядро СУБД.
Связанный контент
Обратная связь
Ожидается в ближайшее время: в течение 2024 года мы постепенно откажемся от GitHub Issues как механизма обратной связи для контента и заменим его новой системой обратной связи. Дополнительные сведения см. в разделе https://aka.ms/ContentUserFeedback.
Отправить и просмотреть отзыв по