Baixa utilização da CPU, mas aguarda sinal alto

Eu tenho um servidor com 16 CPUs que está configurado com um max degree of parallelismde 8 e uma max worker threadsconfiguração de zero.

Por uma determinada hora, minhas esperas de sinal foram de 20%, mas a utilização da CPU do SO durante esse período nunca ultrapassou 25%. Alguém pode explicar por que minhas esperas de sinal eram tão altas?

Meu fornecedor possui o melhor sistema de pontuação da classe, que espera que tenhamos 10% ou menos de espera de sinal ou seremos enganados. Como posso corrigir isso (sem adicionar CPUs adicionais)?

• Como não temos mais de 8 CPUs por nó NUMA, o Trace Flag 8048 não se aplica.
• A maior instância de espera é CXPACKET(70%) e depois PREEMPTIVE_OS_PIPEOPS(20%)
• cost threshold for parallelismestá definido como 50. Devo aumentá-lo? Para quê?
• Esta é uma máquina física (não uma VM), dedicada ao SQL Server.
• Estou usando uma ferramenta de monitoramento para identificar as consultas e procedimentos executados com mais frequência. Quero analisar alta CPU, alta E / S ou alta duração? Normalmente, nosso aplicativo é intensivo em E / S, então eu ajusto E / S alta. Mas, como o problema é sinal de espera, preciso analisar a alta CPU?
• Eu esperava evitar a recomendação de Max Vernon para diminuir MAXDOPpara 4, porque o aplicativo faz algumas consultas no estilo do warehouse que precisam de threads extras.

_{Resposta do Community Wiki gerada a partir de comentários sobre a pergunta de Aaron .}

A menos que você esteja tendo problemas de desempenho, a alta porcentagem de CXPACKETesperas pode ser apenas um indicador de que grande parte das consultas está paralela e na verdade não é um problema.

• Qual é o tipo de espera CXPACKET e como você o reduz?

CPU alta pode ser um indicador, mas pelo que você explicou, diria que olhe para consultas com longas durações, mas com baixa CPU para começar. A CXPACKETespera é por vezes associada a uma consulta à espera de todos os segmentos ao fim antes que possa mesclar os resultados (dados enviesamento).

Se você conseguir modificar as consultas e os procedimentos, poderá definir um valor mais alto MAXDOPpara as tarefas do armazém que precisam dele e definir o valor global MAXDOPmais baixo. No entanto, eu faria isso apenas como último recurso. Você realmente deseja fazer esses tipos de dicas explícitas quando tiver esgotado todas as possibilidades ou não puder fazer alterações no código, nas consultas ou nos esquemas do banco de dados.