Peço desculpas pela duração do meu post.
Recentemente, convertemos nosso sistema de negócios em um produto licenciado pelo número de núcleos. Nós compramos a licença de 2 núcleos e atualmente a executamos no VMWare. É muito caro migrar para o próximo nível de licença.
Estamos tendo alguns problemas de desempenho bastante significativos. Nós eliminamos a RAM como um gargalo, assim como o acesso à rede, banco de dados e disco. Os tempos em que temos problemas nem sempre são caracterizados por altos usos da CPU. Às vezes, o uso da CPU é inferior a 20%, mas a CPU pronta é alta.
Estou pensando na possibilidade de executá-lo diretamente em um servidor físico separado. Desde que eu estou limitado a dois núcleos eu iria selecionar o mais rápido "Single Thread Performance" cpu eu poderia obter, provavelmente, 4 núcleos. Então eu configuraria o sistema de negócios para usar 2 núcleos e permitir que o sistema operacional consuma os outros 2.
Minha lógica é algo assim. No momento, a VM está recebendo dois encadeamentos ou vCPU. Isso é realmente apenas um pCPU. Mesmo se eu movesse para a mesma caixa sem hyperthreading, ele teria 2 núcleos completos em vez de 2 vCPUs. Mas se eu escolher um chip que é muito mais rápido em um único thread, eu poderia ganhar muito mais. Eu também teria um pequeno ganho, já que eu não estaria virtualizando mais.
Nossa cpu atual de 6 núcleos recebe as seguintes pontuações de acordo com a Passmark. CPU Marca: 8570 Desempenho de encadeamento único: 1403
O processador de 4 núcleos que eu quero recebe essas pontuações. Marca da CPU: 10231 Desempenho único segmento: 2287
Faz sentido criar um servidor especificamente para obter o melhor desempenho de encadeamento único para um aplicativo como este? Há algum contras que eu preciso me preocupar? Um novo SO faria uma grande diferença?
O servidor host atual possui as seguintes especificações: Proliant DL380 G7 2 CPUs Físicas: Intel® Xeon® X5675 a 3,07 GHz 6 núcleos cada para 24 processadores lógicos (vCPU) total Hyperthreading está ativado. 144 GB de RAM
O armazenamento está em uma SAN mais recente e tenho certeza de que isso não está afetando nossos problemas de desempenho.
A VM do sistema comercial é configurada com 2 vCPUs e 24 GB de RAM. O SO é o Windows Server 2008 R2. O software do sistema comercial é otimizado para ser executado em 4 - 6 GB de RAM no pool de aplicativos no IIS. Eu nunca vi a VM passar de 16 GB em uso.
Também estamos executando outras três VMs no host. Um está realmente fazendo muito pouco agora e provavelmente será desativado em um futuro muito próximo. Tem 2 vCPU e 8 GB de RAM.
O segundo está executando nosso banco de dados MS Sql. Esse tem 8 vCPU e 64 GB de RAM. Tivemos uma análise do DBA e ele não acha que é a causa de nossos problemas, pelo menos não do lado do desempenho do banco de dados.
A 3ª VM está executando o nosso site público. A média é inferior a 25% na CPU. Tem 3 vCPU e 16 GB de RAM.
Mais uma vez, qualquer ajuda ou sabedoria que você possa fornecer seria incrível e muito apreciada.
Obrigado!
Você está correto em suas suposições. Para o seu caso particular, o empilhamento do Mhz em vez do vCores é um caminho certo a seguir. Dê uma olhada neste processador : (possui 4x núcleos físicos de 3,5-3,7 Ghz + HT).
No entanto, não vejo o problema real a partir do que você descreveu, a menos que você possa fornecer seu valor real "CPU Ready".
Algumas coisas;
1) Tente se limitar a tantas vCPUs que sua VM realmente precise. Isso tem a ver com o agendador de recursos no VMware ESXi, se você tiver uma VM com 8 vCPUs, ele precisa encontrar um intervalo de tempo em uma CPU física que tenha 8 núcleos livres no tempo determinado para executar o ciclo de clock da VM. Portanto, se você tiver 6 núcleos por CPU, o agendador precisará encontrar um período de atividade em ambas as pCPUs, o que basicamente coloca tudo em espera. As VMs não são executadas continuamente como as máquinas físicas, elas são "congeladas" entre ciclos de clock e, se o agendador tiver problemas para manter suas VMs, gastará cada vez mais tempo "congelado". Se você não estiver executando um banco de dados enorme na VM do SQL, tente baixar suas vCPUs para 6 e veja se isso não melhora as coisas. Eu geralmente executo 1 vCPU por padrão, 2 para VMs maiores e até 4 para alguns bancos de dados maiores. Eu nunca vi a necessidade de adicionar mais.
2) Esqueça o HyperThreading no VMware, ele oferece um pouco mais de desempenho, cerca de 10% de acordo com alguns testes da VMware, então deixe-o ligado, mas não conte com 2x vezes o desempenho ao especificar o hardware. / p>
3) As CPUs com taxas de relógio mais rápidas oferecem um desempenho de thread único mais rápido, mas menos núcleos oferecem menos capacidade de executar mais VMs. Há uma razão pela qual o VMware mostra um agregado de toda a velocidade de todos os núcleos no host, que é basicamente como o ESXi vê CPUs, como um conjunto agregado de poder computacional.