Alocação de cpu VMware para um servidor de banco de dados spiking

Question

Eu tenho um servidor de banco de dados com muitas consultas mal escritas que fazem com que o sql server aumente, em seguida, caia constantemente (um grande começo do zero está acontecendo). Eu preciso saber se a alocação de cpu na VM para expandir conforme necessário é a melhor prática para um caso como este. Eu estou querendo saber se a plataforma esxi não pode expandir tão rápido quanto os picos acontecem.

Estou curioso para saber qual é a melhor prática para a alocação de cpu vm no sql server (com consultas terrivelmente escritas)

    

Answer 1

Observe, ajuste e tente dimensionar corretamente suas máquinas virtuais.

Isso é tudo que você pode fazer.

O VMware não possui uma noção de <\> escala automática em termos de adição de recursos adicionais da CPU dinamicamente ... no entanto, a VM usará o que você der a ela. Não há "expansão de recursos" aqui.

por exemplo. Se você alocar 2 CPUs virtuais de 2,8 GHz, a demanda normal de CPU da VM estará em qualquer lugar entre 50MHz e 5600MHz. Veja o sistema em tempo real, veja como ele reage e a partir daí.

    

Answer 2

O gerenciamento da CPU é bastante em tempo real. Na verdade, o tempo de CPU é dividido em 20ms quantums (iirc). Portanto, sempre que houver bastante CPU ociosa, as coisas estarão relativamente bem.

No caso de haver uma contenção de CPU entre o servidor de banco de dados e outras VMs, alguém vai ganhar e alguém perderá.

Você pode jogar com vários fatores: mínimo, máximo e compartilhamentos. Se você não quiser que o banco de dados perturbe outras máquinas, poderá obter baixos compartilhamentos de CPU ou dar a ele um tempo máximo de CPU. Se você quer que o banco de dados tenha alta prioridade, você pode dar a ele um tempo de CPU reservado mínimo ou altos compartilhamentos.

Outro conselho é não dar à VM muita vCPU, pois ela pode ser contraproducente. Nos piores casos, mesmo tendo CPUs físicas ociosas, o sistema pode não conseguir agendar as VMs. Você pode perceber isso por causa dos altos valores "co-stop" nos gráficos de desempenho.

Além disso, se você tiver uma licença DRS, poderá fornecer à VM do DB alguma reserva mínima de CPU, para que o sistema tente acompanhar essa máquina em um ESXi que tenha CPU disponível suficiente.

    

Answer 3

Considere implementar algo como o vCenter Operations Manager para entender melhor esses altos e baixos, e inclua parte dos pacotes selecionados. Dito isto, se você tiver que alocar excessivamente a CPU, haverá pouca desvantagem real.