Привет народ,
У меня есть система SQL Server 2005 с 4 процессорами в каждом с 4 ядрами. В настоящее время он в основном использует всего 4 ядра, т. Е. 4 из них на пике загружены примерно на 90%, а остальные - на 30%. Я предполагаю, что 4 ядра - это по одному от каждого процессора, хотя я не уверен. Кто-нибудь знает такое ожидаемое поведение? Будет ли повышенная нагрузка распределяться на дополнительные ядра вместо дальнейшей нагрузки на текущие 4. Указывает ли это на какие-то другие проблемы, которые мне следует изучить?
При пиковой нагрузке я ожидал, что одновременно будет более 40 подключений, и большинство из них, если не все, будут разрешены для грязного чтения. По этой причине я не думаю, что это как-то связано с рабочей нагрузкой, поступающей на SQL Server, а скорее с тем, как он выбирает использование имеющихся ресурсов процессора.
Спасибо,
Робин
SQL автоматически управляет использованием ЦП по своему усмотрению, в зависимости от максимальной степени параллелизма и порога стоимости параллелизма, которые доступны в расширенных параметрах для sp_configure (см. электронную книгу).
Возможно, вам захочется посмотреть на эти настройки и, возможно, просмотреть сами сценарии SQL.
SQL не имеет средств для управления распределением потоков между физическими ядрами. Это привилегия, которую имеет только ОС. SQL не применяет маски сродства (кроме глобальной настраиваемой маски сродства SQL для ограничения количества процессоров, которые видит SQL). Поведение, которое вы видите, в конечном итоге определяется драйверами материнской платы, драйверами процессора и основной ОС. Я видел подобное поведение, связанное либо с многопоточностью, либо с проблемами драйверов.
В идеале все ядра должны иметь одинаковую нагрузку на ЦП, возможно, одно имеет большую нагрузку на ядро (красная линия) из-за обработки определенных прерываний оборудования (сеть).
Конечно, я предполагаю, что ваша загрузка SQL жестяная банка При распределении между процессорами возникают некоторые очень необычные нагрузки, например, очень мало запросов, но очень интенсивные вычисления, которые не могут быть распределены, но, опять же, это очень необычно в контексте SQL.