SQL Server 2005 - Использование нескольких процессоров

Question

У нас есть 16-процессорный кластер SQL Server 2005. Рассматривая данные об использовании ЦП, мы видим, что в большинстве случаев только 4 из 16 процессоров когда-либо используются. Однако в периоды высокой нагрузки иногда используется 5-й и 6-й процессоры, хотя никогда не бывает рядом с использованием другого 4. Я обеспокоен тем, что в периоды чрезвычайно высокой нагрузки будут использоваться не все остальные процессоры и у нас будет ухудшение производительности.

Это то, что мы видим в стандартном поведении кластера SQL Server 2005? Я предположил, что все 16 процессоров будут использоваться в любое время, хотя это, похоже, не так. Это что-то, что мы можем настроить? Или это ожидаемое поведение? Будет ли SQL-сервер в состоянии использовать все 16 процессоров, если это произойдет?

Answer 1

Я подумаю, что вы сделали должную осмотрительность и подтвердили, что потребление ЦП принадлежит процессу sqlservr.exe, поэтому мы не преследуем красную селедку здесь. Если нет, убедитесь, что процессор потребляется sqlservr.exe, проверив счетчики производительности Process \% Processor.

Вам необходимо понять модель планирования процессора SQL Server, как описано в Thread and Task Architecture. SQL Server распространяет запросы (sys.dm_exec_requests) через планировщики (sys.dm_os_schedulers), назначая каждому запросу задачу (sys.dm_os_tasks), которую выполняет рабочий (sys.dm_os_workers). Работник опирается на нить или волокно ОС (sys.dm_os_threads). Большинство запросов (пакет, отправленных на SQL Server) порождают только одну задачу, некоторые запросы могут порождать несколько задач (наиболее часто встречающиеся запросы).

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

• Hyperthreading. Если вы включили hyperthreading, выключите его. SQL Server и гиперпоточность should never mix.
• Плохие водители. Убедитесь, что у вас установлены правильные драйверы системных устройств (например, для основной платы и т. Д.).

Также убедитесь, что ваш SQL 2005, по крайней мере, на уровне SP2, желательно с последними SP и всеми CU. То же самое касается Windows (вы запускаете Windows 2003 или Windows 2008?).

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

Answer 2

Вы уверены, что вы не являетесь узким местом в другом месте? Возможно, на МО?

Answer 3

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

Мое рассуждение состоит в том, что если бы возникла какая-то проблема с конфигурацией, которая позволяла вам ограничиваться 4-мя процессорами, вы бы не увидели, что она перешла на 5-й и 6-й процессоры.

Answer 4

Даже если учесть узкое место в IO, я бы проверить, установлено ли у вас аффинность процессора, какова ваша настройка maxdop, будь то SMP или NUMA, которые также должны влиять на то, что вы можете установить maxdop.

Когда вы говорите, что у вас 16-процессорный кластер, вы имеете в виду 2 SQL-сервера в кластере с 16 процессорами каждый или 2 x 8-way SQL-серверов?