Esta é uma questão puramente teórica. Digamos que eu tenha um aplicativo implantado em vários servidores.
- Um balanceador de carga,
- Servidores de aplicativos múltiplos/escaláveis
- Um servidor de banco de dados (único) (no momento)
Nas duas primeiras partes, eu sei o que procurar. Mas e o servidor de banco de dados? Que tipo de hardware devo procurar?
- A frequência da CPU é relevante para um servidor de banco de dados?
- As CPUs de vários núcleos são relevantes?
- A RAM é mais importante que a CPU?
PS: Supondo que o banco de dados escolhido seja MySQL ou PostgreSQL.
Para o PostgreSQL, o poder da CPU pode ser muito relevante, especialmente se uma porcentagem bastante alta do conjunto de trabalho ativo de seus dados couber na RAM. A maioria dos bancos de dados com os quais trabalhei teve o poder da CPU como o principal gargalo na maioria das vezes. (Acabei de verificar o vmstat em um servidor que hospeda sites com milhões de acessos por dia hospedando mais de 5 TB de espaço de banco de dados e nunca vi mais de 2% de tempo de espera de disco, mas vi um pico de 12% de tempo de CPU do usuário.)
Como o PostgreSQL é baseado em processos, qualquer processo único pode ser executado tão rápido quanto um núcleo, mas em uma mistura como a que temos no servidor mencionado acima, com um alto volume de pequenas solicitações, a CPU total em todos os núcleos é mais importante. Para a mesma potência total de CPU, o PostgreSQL geralmente se sairá melhor com menos núcleos mais rápidos do que muitos núcleos mais lentos.
Até o ponto em que uma alta porcentagem de seu conjunto de dados ativo é armazenada em cache, adicionar RAM normalmente mostrará mais retorno do que adicionar núcleos. Depois de obter cache suficiente, o benefício da RAM adicional diminui e é melhor aumentar a potência da CPU.
Para mais detalhes sobre este tópico no que se refere ao PostgreSQL, não acho que exista uma fonte melhor do que o PostgreSQL 9.0 High Performance de Greg Smith . (Divulgação completa, eu fui um revisor técnico do livro, mas não obtive nenhum benefício financeiro com base nas vendas.)
Estritamente da perspectiva do MySQL, essa é uma pergunta muito carregada
Embora a CPU e a placa-mãe mais rápidas sejam ótimas, outros gargalos podem atrapalhar. Esses gargalos incluem:
Cada pequena vantagem ajuda, mas devo dizer Não porque a velocidade da CPU, por si só, não melhora os gargalos mencionados. Afinal, de que adianta um carro de corrida de Fórmula 1 com um paraquedas aberto ou com um gorila de 800 libras ao volante?
Isso depende inteiramente de qual versão do MySQL você está executando. Plugin MySQL 5.1 InnoDB, MySQL 5.5 e XtraDB do Percona Server têm configurações que VOCÊ DEVE CONFIGURAR CORRETAMENTE para que o InnoDB acesse todos os núcleos. O verdadeiro incentivo para fazer isso decorre do fato de que algumas versões mais antigas do MySQL LEFT UNCONFIGURED são mais rápidas do que as versões mais recentes, como discuti em meus posts anteriores:
Portanto, se você não estiver disposto a configurar o InnoDB para acessar todas as CPUs, ter vários núcleos não compra absolutamente nada .
Ah, sim mesmo. A configuração de memória para MySQL envolve a configuração
Solicitar muito pouco ou muito de qualquer combinação dessas coisas e o MySQL voltará para mordê-lo. Uma CPU mais rápida com o MySQL configurado incorretamente para RAM apenas faz o MySQL mordê-lo mais rápido.
Em termos simples, você precisa de desempenho de RAM e E/S (latência + velocidade de leitura + velocidade de gravação) para bancos de dados.
A escolha de 4 ou 6 núcleos ou 2,5 GHz vs 3 GHz não é realmente relevante (presumo que você não precise escolher entre um P3-450 com 32 GB de RAM ou o Xeon mais recente com 1 GB de RAM).
Se você estiver limitado à CPU, terá outros problemas (design ruim, índices ruins, troca, servidor não dedicado, etc.)