Esta é uma questão puramente teórica. Digamos que eu tenho um aplicativo implantado em vários servidores.
- Um balanceador de carga,
- Servidores de aplicativos múltiplos / escaloná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 várias CPUs principais são relevantes?
- A RAM é mais importante que a CPU?
PS: Supondo que o banco de dados escolhido seja MySQL ou PostgreSQL.
mysql
postgresql
performance
Zenklys
fonte
fonte
Respostas:
Para o PostgreSQL, a energia da CPU pode ser muito relevante, especialmente se uma porcentagem bastante alta do conjunto de trabalho ativo dos seus dados couber na RAM. A maioria dos bancos de dados com os quais trabalhei tiveram a energia da CPU como 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 no banco de dados e nunca vi mais de 2% de tempo de espera do disco, mas vi um pico de 12% do 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 solicitações pequenas, a CPU total em todos os núcleos é mais importante. Para a mesma potência total da CPU, o PostgreSQL geralmente se sai melhor com menos núcleos mais rápidos do que muitos núcleos mais lentos.
Até o ponto em que uma alta porcentagem do seu conjunto de dados ativo é armazenada em cache, a adição de RAM normalmente mostra mais retorno do que a adição de núcleos. Depois de obter cache suficiente, os benefícios da RAM adicional diminuem e é melhor aumentar a energia da CPU.
Para mais detalhes sobre este tópico no que diz respeito ao PostgreSQL, não acho que exista uma fonte melhor que o PostgreSQL 9.0 High Performance de Greg Smith . (Divulgação completa, fui um revisor técnico do livro, mas não recebi nenhum benefício financeiro com base nas vendas.)
fonte
Estritamente da perspectiva do MySQL, essa é uma pergunta muito carregada
Enquanto CPU e placa-mãe mais rápidas são ótimas, outros gargalos podem atrapalhar. Esses gargalos incluem:
Toda pequena vantagem ajuda, mas devo dizer Não, porque a velocidade da CPU, por si só, não melhora os gargalos acima mencionados. Afinal, de que adianta um RaceCar de Fórmula 1 vestindo um para-quedas aberto ou com um gorila de 800 libras ao volante?
Isso depende inteiramente de qual versão do MySQL você está executando. O MySQL 5.1 InnoDB Plugin, o MySQL 5.5 e o XtraDB do Percona Server têm configurações que DEVE CONFIGURAR CORRETAMENTE para que o InnoDB acesse todos os núcleos. O verdadeiro incentivo para fazer isso deriva do fato de que algumas versões mais antigas do MySQL LEFT UNCONFIGURED são mais rápidas 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 comprará absolutamente nada .
Ah, sim mesmo. A configuração de memória para o MySQL requer a instalação
Solicitando muito pouco ou muito de qualquer combinação dessas coisas e o MySQL volta para morder você. Uma CPU mais rápida com o MySQL configurado incorretamente para RAM apenas faz o MySQL te morder mais rápido.
fonte
Em termos simples, você precisa de desempenho de RAM e IO (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 (suponho que você não precise escolher entre um P3-450 com 32 GB de RAM ou o mais recente Xeon com 1 GB de RAM).
Se você estiver vinculado à CPU, terá outros problemas (design ruim, índices ruins, troca, servidor não dedicado etc.)
fonte