Estou experimentando uma alta porcentagem de espera de sinal enquanto a utilização da CPU está muito baixa em um de nossos servidores.
Eu li vários artigos online sobre Signal Waits e entendo que é o tempo gasto na fila executável, no entanto, ainda estou tendo dificuldade em entender por que o uso da CPU permanece tão baixo (25%) enquanto a porcentagem de Signal Waits é alta (faixa de 75-90%.)
Se uma sessão está esperando por uma CPU disponível para executá-la, por que a utilização da CPU é tão baixa?
relate perguntas
-
SQL Server - Como as páginas de dados são armazenadas ao usar um índice clusterizado
-
Preciso de índices separados para cada tipo de consulta ou um índice de várias colunas funcionará?
-
Quando devo usar uma restrição exclusiva em vez de um índice exclusivo?
-
Quais são as principais causas de deadlocks e podem ser evitadas?
-
Como determinar se um Índice é necessário ou necessário
Não mexa com porcentagens. Seu servidor sempre terá 100% de espera em algo - mas pode não haver muita carga. Seu servidor é o exemplo clássico.
Digamos que você execute apenas 1 consulta por hora. Todos os dados da consulta já estão armazenados em cache na memória e não há mais ninguém competindo por bloqueios. Essa consulta tem várias tarefas paralelas e todas elas precisam obter tempo de CPU.
Essa consulta só vai funcionar por um tempo, então termine. Se você observar as esperas de sinal, pode parecer que 90-100% do tempo, QUANDO ESTAVA ESPERANDO, estava esperando para entrar na CPU. Mas simplesmente não estava esperando tanto.
Em vez disso, observe o tempo de espera por núcleo, por segundo (ou por hora), conforme descrito aqui:
https://www.brentozar.com/archive/2015/03/how-to-measure-sql-server-workloads-wait-time-core-second/
(Isenção de responsabilidade: eu escrevi isso.) Dessa forma, você pode ver se o servidor está realmente fazendo algum trabalho. Aposto que no seu servidor, você está esperando apenas alguns minutos por hora - ou seja, você simplesmente não precisa se preocupar em ajustar esse servidor em geral. Isso não significa que toda QUERY é rápida - significa apenas que você não pode fazer o ajuste no nível do servidor e precisa alternar para o ajuste no nível da consulta. (Você deve perguntar por que a consulta está lenta em vez de perguntar por que o servidor está lento.)