Я буду считать, что вы проявили должную осмотрительность и подтвердили, что использование ЦП относится к процессу sqlservr.exe, поэтому здесь мы не будем гоняться за красной сельдью. Если нет, убедитесь, что ЦП использует sqlservr.exe, проверив счетчики производительности Process \% Processor.
Необходимо понимать модель планирования ЦП SQL Server, как описано в Архитектура потоков и задач . 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. Если вы включили гиперпоточность, отключите ее. SQL Server и гиперпоточность никогда не должны смешиваться .
- Плохие драйверы. Убедитесь, что у вас установлены правильные драйверы системного устройства (для таких вещей, как материнская плата и тому подобное).
Также убедитесь, что ваш SQL 2005 по крайней мере на уровне SP2, желательно не позднее SP и всех примененных CU. То же самое касается Windows (вы используете Windows 2003 или Windows 2008?).
Теоретически поведение также может быть объяснено очень специфической рабочей нагрузкой, т.е. SQL видит только несколько очень длинных и требовательных к ЦП запросов, у которых нет опции parallle. Но это было бы крайне перекос нагрузки, и я никогда не видел ничего подобного в реальной жизни.