Início / dba / Perguntas / 246589
Accepted
AngryHacker
Asked: 2019-08-30 14:25:01 +0800 CST

É normal compartilhar CPUs em uma VM do SQL Server?

  • 772

Nossa TI configurou um SQL Server como uma VM em uma grande caixa VMWare que contém outras VMs. As CPUs são configuradas como compartilhadas. Como resultado, qualquer consulta que possa precisar de várias CPUs demora 30 vezes mais do que se eu a limitasse a uma única CPU. Exemplo:

SELECT TOP 2000 lwa.Message INTO #foo
FROM dbo.LogWidgetsAPI lwa (NOLOCK)
ORDER BY lwa.TimeStamp

vs

SELECT TOP 2000 lwa.Message INTO #foo
FROM dbo.LogWidgetsAPI lwa (NOLOCK)
ORDER BY lwa.TimeStamp
OPTION (MAXDOP 1)  ------------- Force it to run on a single CPU

O primeiro exemplo usa paralelismo e leva cerca de 30 segundos ou mais. O segundo força o uso de uma única CPU e demora 20 milissegundos.

Nota: depois de executar a consulta de CPU única, volto à execução da multi-cpu e o tempo e o plano são os mesmos - então não acho que o problema esteja relacionado a "cache frio" versus "cache quente"

Portanto, minha teoria é que, como a primeira consulta usa várias CPUs, ela deve esperar até que todas as CPUs em questão estejam ociosas e, portanto, apenas espera.

Então minha pergunta. As VMs do SQL Server devem ter CPUs dedicadas ou as compartilhadas são normais?

Aqui está o plano que usa paralelismo. Aqui está o plano que força uma única CPU.

sql-server sql-server-2016

2 respostas

  1. Best Answer

    É normal compartilhar CPUs em uma VM do SQL Server?

    Sim, é bem comum. Muitas vezes, as VMs são usadas para consolidar muitos SQL Servers (especialmente aqueles que não possuem requisitos de desempenho extremos) em um host. Isso pode economizar custos de licenciamento, pois o SQL Server pode ser licenciado no nível do host.

    É uma boa ideia? Quer dizer, depende muito de como a VM está sobrecarregada e de quão intensivas são as cargas de trabalho da CPU.

    Olhando para as capturas de tela dos dois planos de execução, eles são basicamente os mesmos, exceto pelo paralelismo. Uma área problemática no plano paralelo é a zona serial onde mora o operador "Top":

    captura de tela da zona serial no plano paralelo

    Há alguma sobrecarga associada a reunir todas as linhas em um thread e redistribuí-las para a inserção paralela. Eu não esperaria que a sobrecarga fosse de 30 segundos.

    Portanto, minha teoria é que, como a primeira consulta usa várias CPUs, ela deve esperar até que todas as CPUs em questão estejam ociosas e, portanto, apenas espera.

    Não, não é assim que o paralelismo funciona no SQL Server. Os encadeamentos que estão verificando o índice clusterizado no canto superior direito do plano podem realizar níveis de trabalho muito desiguais, dependendo de quão ocupadas estão as diferentes CPUs.

    Agora, se essa instância do SQL Server estiver tão ocupada que todos os threads disponíveis estiverem sendo usados ​​para outras consultas, a consulta paralela poderá estar aguardando THREADPOOL. O que me leva ao meu próximo ponto:

    A consulta paralela provavelmente está aguardando algum recurso. Eu começaria examinando a parte "WaitStats" do plano de execução no SSMS:

    captura de tela do nó waitstats no plano de execução do SSMS

    Isso estará na janela "Propriedades" do operador mais à esquerda em seu plano. Como um exemplo, um SOS_SCHEDULER_YIELDvalor realmente alto nesse caso pode ser um sinal de que essa instância do SQL Server não está ativando a CPU do host. Jonathan Kehayias tem um post muito bom sobre esse tópico aqui:

    Impacto pronto para CPU em SOS_SCHEDULER_YIELD

    Você também pode comparar a proporção entre o tempo decorrido e o tempo de CPU nas duas consultas. Esses números estão na mesma janela de propriedades:

    captura de tela do nó de estatísticas de tempo no plano de execução do SSMS

    Se a proporção for significativamente diferente entre as duas consultas, isso é outro sinal de que a consulta paralela está aguardando algum recurso.

    Se você tiver acesso ao host/virtualização, poderá verificar as estatísticas diretamente para ver se os convidados estão aguardando longos períodos para serem agendados na CPU. Jonathan tem outro post sobre isso aqui, que é específico para VMWare: CPU Ready Time in VMware and How to Interpret its Real Meaning

    • 3

  2. Responder ao conteúdo originalmente deixado nos comentários

    Não, porque o VMWare nem vê o SQL Server, ele vê apenas o Windows. Ele agenda CPUs no nível da VM, não no nível de um processo em uma VM. – Caio

    Você licencia o SQL pelo núcleo... por que você está compartilhando isso com algo diferente do SQL? Sim, o uso excessivo de CPU's é uma prática normal para virtualização, mas normalmente não é feita para SQL. – Jonathan Fit

    Compare os IOs Lógicos para as duas consultas. Se eles estiverem na mesma proporção do tempo decorrido, o hipervisor não será um problema. Você não pode apenas comparar o tempo de CPU aqui, pois um thread de VM pode ser agendado no convidado, mas aguardando o host.– David Browne - Microsoft

    Você precisa monitorar as estatísticas prontas da CPU no host vm para saber se há excesso de assinaturas acontecendo para responder a essa pergunta.

    Uma coisa a ter em mente com VMware e cpus compartilhado é que ele precisa obter o número de vcpus que o vm foi atribuído antes de executar as instruções no cpu.

    Em outras palavras, se sua VM tiver 8 vcpus atribuídos, mas apenas 4 estiverem disponíveis no momento em que tiver instruções para processá-la, terá que esperar até obter todos os 8 antes de continuar.

    Em um host com excesso de assinaturas, você verá com que frequência a VM está aguardando sua vez nos núcleos nas métricas prontas para CPU. Essa métrica com valores regularmente acima de 5% é um forte indicador de que há uma restrição de CPU. – Arão

    • 2

relate perguntas