Oi gente,
Eu tenho um sistema SQL Server 2005, com 4 processadores nele, cada um com 4 núcleos. Atualmente, ela utiliza apenas 4 núcleos, ou seja, 4 pairam em torno de 90% de utilização no pico e os outros mais perto de 30%. Estou assumindo que os 4 núcleos são um de cada cpu embora eu não esteja certo. É este o comportamento esperado alguém sabe? A carga aumentada será distribuída nos núcleos adicionais, em vez de ser carregada ainda mais na corrente 4. Isso é indicativo de algum outro problema que eu deveria investigar?
No pico de carga, eu esperaria pelo menos 40 conexões simultaneamente, pelo menos, e a maioria, se não todas, será configurada para permitir leituras sujas. Por essa razão, não acho que tenha a ver com a carga de trabalho que chega ao SQL Server, e sim como ele escolhe usar os recursos de CPU disponíveis.
obrigado,
Robin
O SQL gerencia automaticamente o uso da CPU da maneira que julgar adequada, dependendo do grau máximo de paralelismo e do limite de custo do paralelismo, ambos disponíveis nas opções avançadas de sp_configure (consulte os manuais online).
Você pode querer ver essas configurações e, possivelmente, revisar os próprios scripts SQL.
O SQL não possui os meios para gerenciar a alocação de encadeamentos para núcleos físicos. Isso é um privilégio apenas o sistema operacional tem. O SQL não impõe máscaras de afinidade (curto da máscara de afinidade ampla configurável global do SQL para limitar o número de CPUs que o SQL vê). O comportamento que você vê é basicamente impulsionado pelos drivers da placa-mãe, pelos drivers da CPU e pelo sistema operacional central. Eu tenho visto um comportamento similar associado a multi-threading ou associado a problemas de driver.
O comportamento ideal é ter todos os núcleos compartilhando uma carga de CPU igual, talvez tendo uma carga de kernel maior (linha vermelha) devido ao processamento de certas interutilizações de hardware (rede).
É claro que eu suponho que sua carga de SQL pode ser distribuída entre CPUs, existem algumas cargas muito incomuns como ter muito poucos pedidos mas muito intensos em computação que não podem ser espalhados, mas, novamente, são muito incomuns no contexto do SQL.