Mais núcleos de CPU vs discos mais rápidos

Faço parte de uma pequena empresa, cobrindo, como de costume, várias funções diferentes. O último deles é a aquisição de uma caixa dedicada do SQL Server para nosso aplicativo Web .NET. Fomos citados em uma configuração de CPU dupla Xeon E5-2620 (seis núcleos) de 2,00 GHz (12 núcleos no total), com 32 GB de RAM. Isso nos deixou um orçamento limitado para a matriz de discos, que consistiria basicamente em duas unidades SAS de 300 GB de 2,5 "(15k RPM) em uma configuração RAID 1.

Eu sei que a configuração do disco não é ideal para o SQL Server e eu realmente gostaria de usar o RAID 10 para que possamos colocar o banco de dados, os arquivos de log e o tempdb em suas próprias unidades. Para tornar isso compatível com nosso orçamento, devo considerar reduzir o número de núcleos de CPU? ou eu ficaria melhor com o banco por manter os núcleos e usar menos unidades, talvez 4 em uma configuração dupla de RAID 1?

Aqui estão algumas estatísticas adicionais

• O banco de dados do SQL Server é inclinado para um número alto de leituras para gravações, provavelmente 80% vs 20%, respectivamente. O tamanho atual do banco de dados é de cerca de 10 GB e 26 GB no momento, crescendo a uma taxa de 250 MB por mês.

• Atualmente em execução no SQL Server 2008 R2 Standard em uma única caixa Xeon de quatro núcleos compartilhada com o servidor Web (12 GB de RAM, 2 x 10k unidades SAS de 300 GB no RAID 1), procurando migrar para o SQL Server 2012 Standard.

• O banco de dados atende a aproximadamente 100-150 usuários simultâneos, com algumas tarefas de agendamento em segundo plano. Lendo isso, estou pensando que 12 núcleos são um sério exagero!

Implantei o aplicativo inteiro em um serviço de nuvem do Azure (2 pequenas instâncias) vinculado a um banco de dados do SQL Azure. Embora o desempenho fosse razoável ao testar (carga quase nula), perdi a coragem de usar na produção devido à imprevisibilidade sobre a qual eu havia lido tanto. Pode funcionar melhor com uma abordagem de escalabilidade horizontal, mas com apenas um banco de dados de 10 GB, eu provavelmente posso continuar escalando agora e economizar algum dinheiro.

Inicialmente, ignorei os custos de licenciamento e não percebi que o licenciamento do SQL Server 2012 se baseia no número de núcleos. Eu tenho uma assinatura do BizSpark MSDN com uma licença do SQL Server 2012 Standard, então eu precisaria ler quantos núcleos isso usaria imediatamente.

Falando de experiência humilde, mas acho que vale a pena compartilhar, o principal gargalo dos bancos de dados SQL (Sybase e SQL Server aqui) é o armazenamento.

Mas acho justo que alguém primeiro faça um benchmark de sua configuração antes de fazer suposições erradas. No meu caso, o uso da CPU nunca subiu o suficiente para justificar a atualização da CPU tão cedo. Em vez disso, atualizei da unidade única para o RAID 1 e depois para o RAID 10 + um aumento de 8 GB para 16 GB de RAM.

Todas essas atualizações de RAID ajudaram a reduzir o tempo de espera anterior em um fator de 2 a 6. Eu suspeito que atualizar para SSDs seria ainda melhor. Se você pensar bem, tudo poderá ser reduzido à largura de banda (teórica). Seu combo [(Velocidade da RAM + Tamanho da RAM + Controlador de memória) com CPU] tem um limite de largura de banda que seria o fator mais importante nas operações de leitura quando seus dados sempre deveriam ser armazenados em cache, seu armazenamento (RAID) específico tem um limite de largura de banda ( afeta leituras quando o cache está faltando e grava durante a descarga ou com muitos clientes gravando muitos dados combinados).

Normalize todos esses limites o máximo possível (aproxime-os para que você não desperdice recursos) e aumente-os o máximo possível (faça upgrade quando necessário e somente se necessário, não deixe que os recursos sejam desperdiçados se o sistema vencer ' não pode usá-los porque existe algum outro gargalo). No final, seu pior gargalo será o subsistema de servidor com menos desempenho (com menos largura de banda) em sua configuração específica.

Também devo acrescentar que, no processo de atualização, criei configurações RAID separadas para os arquivos e os arquivos de log do banco de dados. O motivo foi que os arquivos de log do banco de dados tendem a ser intensivos em gravação. Um arquivo de log é usado para recuperar um banco de dados de uma falha e é sempre gravado imediatamente quando uma transação é confirmada antes que qualquer dado seja gravado no arquivo de banco de dados.

Um arquivo de log também é usado por alguns servidores de replicação de banco de dados, mas a maior parte da replicação não é feita instantaneamente, mas frequentemente, portanto o impacto no desempenho de leitura é mínimo aqui. Pelo menos acho que sim. Fiz comparações mínimas ao fazer essa atualização novamente. Recomendo que qualquer um primeiro faça um benchmark de suas diferentes configurações e primeiro atualize seu armazenamento, depois RAM e link de rede, antes de pensar em atualizar suas CPUs.

Após atualizações mais extensas em mais de 5 servidores, voltei para compartilhar minha experiência. Eu definitivamente ainda defendo a primeira atualização de armazenamento, depois a RAM e depois a CPU. O motivo é a disparidade de larguras de banda no sistema entre armazenamento, RAM e CPU, na ordem do menor para o maior. Então, atualizei vários servidores de RAID10 e RAID1s duplos para SSDs.

A maneira como fiz isso por questões de custo (tenho mais 20 servidores para atualizar) é mover os arquivos de dados e objetos do banco de dados para um SSD (sim, apenas um SSD no RAID0) e mover o log de transações mais tempdb para um 4xHDD RAID10 configuração. Testei com o tempdb no SSD também com ótimos resultados (na verdade, resultados muito bons com consultas mais de 15 vezes mais rápidas às vezes, produzindo alguns relatórios que demoravam segundos em vez de minutos no passado), mas depois movi o tempdb para o disco RAID10 porque preocupações intensivas de desgaste de gravação para o SSD.

Portanto, agora basicamente observei tempos de resposta de 10 a 15 vezes mais rápidos para algumas das consultas mais longas. O SSD é ótimo para ler dados na RAM rapidamente, porque o SQL Server não os traz até que sejam solicitados e, é claro, os dados primeiro precisam ser carregados na RAM para serem processados ​​pela CPU (posteriormente, no cache L1, L2, L3) , então os SSDs ajudam a reduzir esse tempo de espera inicial por um grande fator. E os SSDs também ajudam a reduzir o tempo de troca ... limpando a RAM e carregando novos dados, especialmente se o banco de dados for maior do que o que pode caber na RAM.

No geral, estamos muito satisfeitos e continuamos executando isso por vários meses, em uma espécie de processo de migração lento, para permitir que os servidores funcionem, para que eu possa coletar informações sobre o nível de desgaste antes de mudar todos os meus servidores para essa configuração. E isso é apenas o SQL Server Express! : D - Apenas certifique-se de que seus SSDs possam fornecer IOPS constante, porque isso é outra coisa que faz uma enorme diferença (basta pesquisar no Google). Por isso, escolhi os SSDs da série Intel DC (DataCenter).

De certa forma, não é a resposta que você provavelmente está procurando na primeira parte, mas: você já pensou em empurrá-la para a nuvem? A AWS pode permitir que você forneça a maioria das necessidades acima e amplie seu poder de compra sem precisar lidar com o hardware também.

Segunda parte - O hardware realmente depende das tarefas. Costumo me inclinar para mais CPUs quando consigo fazer a integração personalizada do CLR, porque então posso otimizar soluções verdadeiramente paralelas para problemas. Na maioria das vezes, se é melhor ter soluções baseadas em conjuntos, acho que a velocidade da RAM e do disco rígido é o maior gargalo, e o segundo parece ser o seu caso. (Onde a idéia do SSD acima seria útil)

Sem estatísticas reais do seu servidor, sugiro que você procure algumas soluções de cache para diminuir as gravações (a menos que esteja fazendo algum tipo de registro com as gravações ou coisas que precisam de histórico) e colocando muito mais dinheiro em seus discos rígidos do que CPU. O servidor SQL é muito bom em paralelo nas consultas (se elas forem escritas para isso), mas se você for pesado em gravações, seu disco rígido será o verdadeiro gargalo.