Когда менять максимальные рабочие потоки SQL 2005 на 64-битном сервере
Серверная среда:
- Windows 2003 Standard R2 x64 SP2
- SQL 2005 Enterprise 64-разрядный пакет обновления 2
- Процессоры HP ProLiant BL460c G1, Xeon E5440 2,83 ГГц (четырехъядерный)
- 8 ГБ ОЗУ
РЕДАКТИРОВАТЬ: я должен также отметить, что max_workers_count в настоящее время по умолчанию 512 для 4-процессорного блока
Мы сталкиваемся с тупиками потоков потоков, которые, я уверен, связаны с параллелизмом. Графики взаимоблокировок почти идентичны тем, что были в посте Барта Дункана о взаимоблокировках внутри-запросов параллельных потоков, и я не вижу никаких упоминаний о ресурсах блокировки в выходных данных взаимоблокировок, как упомянуто в разделе "Предостережения" его поста, и это приводит меня к выводу. верить, что это вещь параллелизма.
Я нахожусь в процессе настройки запросов, которые выглядят связанными с ними, но это займет немного времени (читай "пару недель"). В то же время мне интересно, было бы целесообразно увеличить пул потоков в качестве временного обходного пути.
Любой SQL Jocks хочет помочь парню?
(Кстати, переход на SP3 сейчас не вариант из-за этой проблемы)
2 ответа
Увеличение количества рабочих не повлияет на ваш тупиковый сценарий вообще, если это связано с параллелизмом, как в сообщении в блоге Барта Дункана. Если это действительно параллельная взаимоблокировка, вы можете быстро исправить OPTION(MAXDOP n) ошибочного запроса, пока вы работаете над его настройкой, и ограничить его до точки, где взаимоблокировка прекращается. Возможно, вам не обязательно возвращаться к DOP 1, я видел, как DOP 4 исправлял это раньше.
Еще одна вещь, на которую стоит обратить внимание, - если на сервере включена гиперпоточность, отключив ее. SQLOS создает пользовательский планировщик для каждого логического ЦП, доступного для SQL Server. С гиперпоточностью вы получаете 8 логических процессоров, что означает, что у вас есть 8 пользовательских планировщиков. Ваш запрос может выполняться в DOP 8, когда у вас действительно есть 4 процессора, что может привести к вашей проблеме. Вы можете определить, является ли это частью проблемы, подсчитав количество узлов процесса в графике тупиковой ситуации XML. Если у вас 8 узлов процесса, попробуйте отключить гиперпоточность на сервере и посмотреть, решит ли это проблему.
Посмотрите эту запись в Books Online, чтобы узнать, как ее изменить: параметр max максимальных рабочих потоков, а также посмотрите обсуждение увеличения максимальных рабочих потоков из старого блога Кена Хендерсона. Я был бы очень осторожен, если бы это не было абсолютно необходимо.
Надеюсь это поможет!