Limitar o uso máximo da CPU SQL SERVER com WSRM


10

Eu tenho um servidor físico executando uma instância do SQL Server.

Percebo que muitas vezes esse servidor está executando com 100% de uso da CPU.

Minha equipe de TI não está feliz com isso e sugeriu que reservássemos dois dos 32 núcleos para o sistema operacional.

Isso funciona muito bem, agora o pico máximo de uso é inferior a 90%. Além disso, a recuperação lenta de dados de vários usuários não é mais relatada.

Existe algum motivo para NÃO usar o WSRM (Windows System Resource Manager) dessa maneira - em vez do SQL Resource Governor?


Você realmente quer usar toda a CPU? Salvar alguns núcleos para o sistema operacional parece prudente, não é? Na minha estação de trabalho, se eu usar todos os núcleos para processar alguns números, minha máquina será interrompida. Eu sempre mantenho alguns núcleos livres. Isso também não seria uma boa prática em uma máquina dedicada ao SQL Server?
ManInMoon 20/03/19

Que tipo de carga está sendo executada neste servidor? Que tipo de processo está usando 100% da CPU? Isso é OLTP ou analítico ou gráfico ou?
Max Vernon

@Forrest Quando você diz sobre o ajuste - você quer dizer o próprio SQL Server - ou a estrutura de consultas / tabela? Se você quer dizer SQL Server, por favor, me dê um link para o que ver. Se perguntas / tabelas, eu as opto quando posso, mas alguns usuários têm menos consciência do design!
ManInMoon 20/03/19

Respostas:


14

Existe alguma razão para NÃO usar a abordagem que você definiu? Absolutamente.

Imagine que você comprou um carro - um carro que, quando você atinge 50 MPH, o motor começa a superaquecer. Sua reação a essa situação seria limitar artificialmente o carro a 49 MPH ou descobrir qual é o problema do motor?

Por que você deve limitar seu carro a 49MPH? O fabricante afirmou que poderia dirigir tão rápido quanto 80MPH - você gosta de dirigir seu carro rápido e deseja alcançá-lo nessa velocidade - se não fosse por esse maldito problema de superaquecimento.

O carro que você comprou também era muito, muito caro. Cada cilindro do motor precisa ser utilizado ao máximo para que você não desperdice esse dinheiro!

Ao limitar artificialmente o acesso dos servidores SQL à CPU, você perde desempenho. Você pode ter resolvido temporariamente os problemas de desempenho, garantindo que a CPU esteja disponível para o sistema operacional, mas você não respondeu à pergunta real - POR QUE o SQL Server está usando 100% da CPU?

Meu conselho é o seguinte:

Descubra qual é o problema real e corrija-o. Não cubra a questão com o que é efetivamente um argumento. A questão vai reaparecer e bater-lhe na cara para baixo da linha quando a carga de trabalho do servidor aumenta naturalmente com o crescimento.

Como uma correção temporária , o administrador de recursos pode ser usado para diminuir a CPU usada, ATÉ QUE VOCÊ ENCONTRE O PROBLEMA REAL.


11

Erik Darling mencionou a maior razão prática para não usar o WSRM em um comentário sobre sua pergunta:

... não há limite recíproco de uso da CPU em outros processos. O SQL Server pode não usar esses dois núcleos, mas outras coisas podem usar os outros 30 que o SQL Server está usando. É realmente um jogo de dados.

Se isso estiver funcionando para você, fique com ele - estamos todos ocupados e você pode gastar tanto tempo em qualquer problema. A solução ideal seria corrigir as questões / questões subjacentes que estão direcionando a CPU ao ponto de problemas perceptíveis pelo usuário (que George aborda em sua excelente resposta ).

Erik continua dizendo

Além disso, você está pagando o licenciamento do SQL Server por eles.

Do ponto de vista comercial, essa é provavelmente a pior parte do negócio do WSRM - você está pagando licenciamento por núcleo para 2 núcleos que não estão sendo usados ​​explicitamente. No momento da redação deste artigo, restam US $ 3 mil ou US $ 14 mil em cima da mesa (dependendo do padrão x do Enterprise).

Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.