Considerações ao escolher processadores AMD sobre Intel


13

Eu trabalho para uma empresa com muitas aplicações Web LAMP herdadas, onde estamos tentando atualizar nosso hardware de ~ 250 servidores físicos para ~ 40 novos servidores com virtualização. Recebemos duas cotações de fornecedores - uma está sugerindo processadores Intel, a outra AMD.

Uma coisa que eu gosto nas altas contagens de núcleos com a AMD é que poderemos dedicar núcleos às VMs, o que significa que temos uma chance menor de os aplicativos interferirem entre si devido a picos, o que, em certa medida, é mais importante para mim do que o desempenho máximo.

As outras considerações que tenho em mente são:

  • O consumo de energia pode ser diferente (não é um problema no nosso caso).
  • Instruções de CPU como CRC32 (SSE 4.2) não serão suportadas (Edit: MySQL 5.6 parece suportar SSE4.2. Não tenho certeza sobre o Apache)
  • O MySQL não escala perfeitamente após ~ 16 / ~ 32 núcleos (estou disposto a aceitar essa troca).

Que outras considerações estou faltando?

(Observação para moderadores: conheço esse tópico - considero a pergunta um pouco diferente.)


Editar: Suponha que as tarefas sejam excepcionalmente paralelas (servidores da web) e que eu não me importo com o fato de os servidores de banco de dados não serem tão paralelos.


você pode achar isso interessante: it20.info/2007/10/intel-amd-vmware-and-aircrafts
ToastMan

Se seu aplicativo pode dividir consultas de leitura / gravação em diferentes pools de servidores, você poderá contornar alguns dos problemas de desempenho do MySQL executando uma segunda instância para a leitura secundária de escravos. Não sei o suficiente sobre sua arquitetura ou carga de trabalho para saber se essa é uma ideia viável ou se isso apenas adicionará uma tonelada de sobrecarga e complexidade desnecessárias, mas é uma opção a considerar.
Jgoldschrafe

Estou familiarizado com o funcionamento da divisão de leitura / gravação. Não é adequado para um ganho de desempenho neste caso.
Morgan Tocker 24/10/11

Respostas:


10

Houve uma boa quantidade de informações sobre a mais recente oferta de processador AMD, chamada Bulldozer. A versão "Servidor" desta parte ainda não foi lançada, mas a oferta da área de trabalho é uma excelente visão de alguns dos possíveis problemas das novas coisas.

Quanto à geração atual da parte do servidor, apesar de tudo, a recomendação é bastante boa em nível genérico. O trabalho de veiculação na Web e (a maioria) de banco de dados é amplamente baseado em Inteiro, e as CPUs AMD se dão bem com a computação de Inteiro. Além disso, a veiculação na web é (genericamente) um problema que pode ser altamente paralelizado. A AMD está se concentrando especificamente em "muitos núcleos tornam o trabalho mais rápido" e o LAMP (novamente, genericamente) tende a responder bem a isso.

Uma área em que você realmente precisa prestar atenção são as dependências de thread único em seus aplicativos. As peças da AMD não são tão dimensionadas quanto as peças da Intel, de modo que os processos que são fundamentalmente de thread único podem prejudicar o sistema geral muito mais rápido do que em peças de CPU mais rápidas. Só você sabe se isso se aplica a você ou não. Certas operações de banco de dados podem ser melhor atendidas a partir de processadores Intel mais rápidos, com contagens de núcleos menores, apenas para que esses poucos threads gordos possam realmente gritar.

O código do aplicativo também é importante aqui. Alguns processos de servidor da web de longa execução poderiam consumir muito tempo de thread único e também gostaria de um relógio mais rápido. Isso pode ser solucionado através da reescrita da necessidade desse longo processo, mas até então um relógio mais rápido seria bom.

Mas, em geral, para cargas de trabalho no estilo lotes-o-servidor-web-vm, essas partes de 12 núcleos podem ser escalonadas até agora. Se você se deparar com alguns problemas de thread único, seguir as partes com 8 núcleos com maior freqüência seria um compromisso aceitável.


Obrigado, infelizmente, o sistema AMD não será um trator. É um AMD Opteron 6140 (ou similar).
Morgan Tocker

@MorganTocker Por acaso, estou familiarizado com essa classe de CPU, e foi para isso que escrevi minha postagem. A escavadeira tem alguns problemas específicos em que eu não entrei.
sysadmin1138

4

Na maioria das vezes, você encontrará os dois processadores muito comparáveis. Os processadores AMD têm uma ligeira vantagem nas velocidades de RAM (geralmente) devido ao quarto canal. Os processadores Intel geralmente têm um CPI mais baixo (possivelmente mais com o HT , embora isso dependa muito da carga de trabalho). AMD são geralmente mais baratos.

A maioria desses fatores dará uma vantagem a um ou outro, dependendo da sua carga de trabalho. Nenhum dos dois será significativamente pior que o outro (assumindo configurações sãs e CapEx aproximadamente igual).


2

Você deve considerar as diferenças de desempenho que a arquitetura de RAM diferente pode trazer e se esse é um fator decisivo para sua organização.

Também como uma observação secundária, embora você possa não estar preocupado com o desempenho máximo, se as VMs não tiverem vários núcleos cada e / ou tarefas específicas dentro forem de thread único, há uma vantagem considerável de desempenho nos intels por núcleo do que a AMD, mesmo que a contagem total de núcleos seja menor.


Suponha que nossos aplicativos sejam adequadamente multiencadeados (servidores web estão; dispostos a aceitar que o MySQL não é totalmente).
Morgan Tocker

2

A principal diferença está na abordagem; na faixa intermediária, a AMD enfatiza levemente os núcleos em uma parte que custa tanto quanto uma parte semelhante à Intel. A parte da Intel terá menos núcleos com clock mais alto.

Portanto, para cargas de trabalho de aplicativos Web virtualizados, você provavelmente desejará favorecer os sistemas AMD.

A menos que haja uma grande diferença de preço, eu não me preocuparia com dólares. Eu procuraria mais o subsistema de E / S. E, o TCO em 40 servidores será principalmente de suporte, licenciamento de software, se houver, e equipe, provavelmente não os próprios servidores.

No mínimo, você precisa fazer um favor a si mesmo, atrair os dois fornecedores e executar seus sistemas no hardware deles antes de se comprometer com 40 servidores de qualquer um deles. Somente você pode responder à pergunta corretamente para sua carga de trabalho específica.


Obrigado pela sua resposta! Não temos uma carga de trabalho - temos várias. Portanto, para atrair o fornecedor, precisamos migrar totalmente e, em seguida, migrar novamente para experimentar os dois. Sei que é o ideal, mas não é prático no nosso caso. Podemos escolher um número menor de papéis para mover e projetar, mas para fazer isso, precisamos saber o que devemos medir / procurar; daí a minha pergunta;)
Morgan Tocker

Por carga de trabalho, quero dizer que você tem uma carga de trabalho GERAL que consiste em (presumivelmente) muitos servidores diferentes fazendo coisas diferentes. Hoje em dia, você deve converter um subconjunto de servidores principais em imagens virtuais com bastante facilidade (com um software que pode ajudá-lo) que pode ser carregado nos servidores que você está prestes a comprar. Não é uma tarefa negligenciável, mas a única maneira de garantir que não apenas a CPU, mas o subsistema de E / S e tudo mais funcionem a seu favor. Caso contrário, todos estão renunciando à mão e tentando adivinhar. :)
alphadogg

1

Mais uma coisa a ser lançada, cuidado: se você usa virtualização de qualquer tipo, migrar os convidados da Intel para a AMD pode ser um problema real e o agrupamento entre as marcas não está nos cartões. Atenha-se a uma plataforma para cada cluster e aceite que é difícil pular de uma para outra.


A migração ao vivo entre arquiteturas com o KVM parece não ser um problema em 64 bits: linux-kvm.org/page/…
Ophidian

O usuário disse "LAMP herdado"; cheira como se houvesse convidados de 32 bits para mim. Ainda assim, é bom saber que a KVM está superando o problema! Obrigado pela observação.
Mark

Sim, alguns convidados têm 32 bits, mas planejamos mudar e ter 64 bits.
Morgan Tocker 26/10/11
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.