Processadores XEON 8 núcleos para processos pesados [fechados]

Question

Não tenho certeza se esse é o grupo certo para minhas dúvidas, mas precisava ter certeza do que vou comprar. Eu já fiz minha pesquisa e não tenho certeza disso, já que esta é minha primeira vez fazendo isso. Estou planejando hospedar meu próprio servidor de desktop e decidi usar um processador XEON com pelo menos 8 núcleos e 32GB de memória RAM. Mas eu não tenho certeza se este é o servidor certo para mim. Meu aplicativo precisa processar pelo menos 20.000.000 de consultas SQL por hora e tem processos de missão crítica que precisam ser rápidos quanto possível.

    

Answer 1

Existem algumas considerações que você deve levar em conta (e que não são aparentes no seu post). Estes incluem -

1. Você quer o máximo de RAM possível - idealmente o suficiente para ajustar todo o conjunto de dados na memória.

2. Se você estiver fazendo um número significativo de gravações e / ou seus dados não couberem totalmente na memória, você precisará do disco mais rápido possível - não sei o tamanho do seu conjunto de dados, mas RAIDED SSDs PCI-E são uma boa ideia - como você fala sobre ser "missão crítica". Sim, não há problema em colocar um banco de dados no SSD - apenas orçamento para substituí-los a cada 5 anos ou mais.

3. Você mencionou um "servidor de desktop". Eu não acredito que este termo exista - é um desktop, estação de trabalho ou servidor. Espero que você queira dizer um Servidor no que era conhecido como um caso de desktop / fator de forma - se esse for o caso, eu sugeriria algo que se encaixaria em seu lado em 4u - o que é bastante fácil de encontrar se você souber procurar para isso. Naturalmente, a maioria dos casos de desktops tem apenas 1 PSU - o que pode ser um problema para confiabilidade e disponibilidade - os servidores de missão crítica geralmente têm 2 PSUs em 2 fases diferentes.

4. Um grande número de (núcleos mais lentos) é provavelmente melhor que os mais rápidos, mas isso dependerá do seu banco de dados e até mesmo do tipo de consultas (por exemplo, o Postgres 9.5 não dividiria uma única consulta complexa entre vários núcleos - mudando para o Postgres 9.6, resultando em um aumento de velocidade próximo a linear em algumas consultas únicas com mais núcleos - portanto, verifique seu banco de dados). Da mesma forma, você deve realmente observar a fragmentação de seu banco de dados para que seja menos um gargalo e possa implantar servidores adicionais conforme necessário.

5. Se a sua missão crítica, você também precisa considerar a replicação - e uma vez que você está indo por esse caminho, pode (ou não) fazer sentido ter um servidor fazendo leitura-escrita, e o outro sendo um read-write. somente escravo - e modificando seu aplicativo para tirar proveito disso. Novamente - eu me pergunto se "missão crítica" foi a palavra correta para descrever seu uso.

6. Como um aparte - você precisa considerar "Meltdown" e seu desempenho. O desempenho do banco de dados pode sofrer 20-30% se você adicionar mitigações a ele. Se você não está mitigando - você precisa estar ciente - e gerenciar os riscos (ou seja, certifique-se duplamente de que é impossível executar código arbitrário nele - incluindo garantir que não há como fazer um ataque de injeção SQL)

Apesar do que os outros disseram, se as suas consultas forem simples o suficiente, é possível fazer 5000 consultas por segundo - veja link