Faço parte de uma pequena empresa, portanto, como sempre, exerço várias funções diferentes. O mais recente deles é a aquisição de uma caixa SQL Server dedicada para nosso aplicativo da Web .NET. Fomos citados em uma configuração de CPU dual Xeon E5-2620 (seis núcleos) de 2,00 GHz (12 núcleos no total), com 32 GB de RAM. Isso nos deixou com um orçamento limitado para a matriz de disco, que consistiria essencialmente em duas unidades SAS de 300 GB de 2,5" (15k RPM) em uma configuração de RAID 1.
Sei que a configuração do disco está abaixo do ideal para o SQL Server e gostaria muito de implementar 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 a redução do número de núcleos de CPU? ou eu conseguiria um banco melhor por dinheiro mantendo os núcleos e usando menos unidades, talvez 4 em uma configuração de RAID 1 duplo?
Aqui estão algumas estatísticas adicionais
O banco de dados do SQL Server é inclinado para altos números de leituras para gravações, provavelmente 80% contra 20%, respectivamente. O tamanho atual do banco de dados é de cerca
de 10 GB26 GB no momento, crescendo a uma taxa de 250 MB por mês.Atualmente rodando no SQL Server 2008 R2 Standard em uma única caixa Xeon quad core compartilhada com o servidor web (12 GB de RAM, 2 unidades SAS de 300 GB x 10k em RAID 1), procurando migrar para o SQL Server 2012 Standard.
O banco de dados atende aproximadamente 100-150 usuários simultâneos com algumas tarefas de agendamento em segundo plano. Lendo isso, estou pensando que 12 núcleos é um exagero sério!
Implantei todo o aplicativo em um serviço de nuvem do Azure (2 pequenas instâncias) vinculado a um banco de dados SQL Azure. Embora o desempenho fosse razoável nos testes (carga quase zero), perdi a coragem de usar na produção devido à imprevisibilidade sobre a qual tanto li. Pode funcionar melhor com uma abordagem de expansão, mas com apenas um banco de dados de 10 GB, provavelmente posso fazer a expansão agora e economizar algum dinheiro.
Inicialmente, negligenciei os custos de licenciamento e não percebi que o licenciamento do SQL Server 2012 é baseado no número de núcleos. Eu tenho uma assinatura do BizSpark MSDN com uma licença do SQL Server 2012 Standard, então preciso ler quantos núcleos isso utilizaria imediatamente.
Falando por experiência que é humilde, mas acho que vale a pena compartilhar, o maior gargalo com 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 aumentou o suficiente para justificar a atualização da CPU tão cedo. Em vez disso, atualizei de unidade única para RAID 1 e depois para RAID 10 + um aumento de 8 GB para 16 GB de RAM.
Todas essas atualizações de RAID ajudaram a reduzir os tempos de espera anteriores em um fator de 2 a 6. Suspeito que atualizar para SSDs seria ainda melhor. Se você pensar sobre isso, tudo pode ser reduzido a largura de banda (teórica). Sua combinação [(Velocidade da RAM + Tamanho da RAM + controlador de memória) para a CPU] tem um limite de largura de banda que seria o fator mais importante nas operações de leitura quando seus dados sempre devem ser armazenados em cache, seu armazenamento (RAID) específico tem um limite de largura de banda ( afeta as leituras quando o cache é perdido e as gravações durante a liberação ou com muitos clientes gravando muitos dados combinados).
Normalize todos esses limites o máximo possível (aproxime-os para que você não tenha recursos desperdiçados) e aumente-os o máximo possível (atualize onde necessário e somente se necessário, não deixe que os recursos sejam desperdiçados se o sistema não funcionar). não poder usá-los porque algum outro gargalo está no caminho). No final, seu pior gargalo será o subsistema de servidor de menor 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 de RAID separadas para os arquivos de banco de dados e os arquivos de log do banco de dados. O motivo era que os arquivos de log do banco de dados tendem a ser gravados intensivamente. 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 com frequência, portanto, o impacto no desempenho de leitura é mínimo aqui. Pelo menos eu acho que sim. Fiz benchmarking mínimo ao fazer essa atualização, então, novamente, recomendo que todos primeiro façam benchmarks de suas diferentes configurações e primeiro atualizem seu armazenamento, depois a RAM e o link de rede, antes de pensar em atualizar suas CPUs.
Depois de atualizações mais extensas em mais de 5 servidores, voltei para compartilhar minha experiência. Eu definitivamente ainda defendo primeiro a atualização do armazenamento, depois da RAM e depois da CPU. O motivo é a disparidade de larguras de banda no sistema entre armazenamento, RAM e CPU, da menor para a 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 dados do banco de dados e arquivos de objetos para um SSD (sim, apenas um SSD em RAID0) e mover o log de transações mais o 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, gerando alguns relatórios que demoravam segundos em vez de minutos no passado), mas depois movi o tempdb para o disco RAID10 porque de preocupações intensivas de desgaste de gravação para o SSD.
Agora, basicamente, observei tempos de resposta 10 a 15 vezes mais rápidos em algumas das consultas mais longas. O SSD é ótimo para ler dados na RAM rapidamente porque o SQL Server não traz dados para a RAM até que seja solicitado e, claro, os dados primeiro precisam ser carregados na RAM para serem processados pela CPU (mais tarde, no cache L1,L2,L3) , então os SSDs ajudam a reduzir o tempo de espera inicial por um fator enorme. E os SSDs também ajudam a reduzir os tempos de troca... limpando a RAM e carregando novos dados, especialmente se seu banco de dados for maior do que cabe na RAM.
Em suma, estamos muito satisfeitos e estamos funcionando assim há 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 de nível de desgaste antes de mudar todos os meus servidores para esta configuração. E este é apenas o SQL Server Express! :D - Apenas certifique-se de que seus SSDs podem fornecer IOPS constantes, porque isso é outra coisa que faz uma grande diferença (basta pesquisar no Google). É por isso que escolhi os SSDs da série Intel DC (DataCenter).
Um pouco não é a resposta que você provavelmente está procurando na primeira parte, mas: você já pensou em enviá-lo para a nuvem? A AWS pode permitir que você atenda à maioria das necessidades acima e aumente seu poder de compra sem ter que lidar também com o hardware.
Segunda parte - O hardware realmente depende das tarefas. Costumo me inclinar para mais CPUs quando posso fazer integração CLR personalizada, porque posso otimizar soluções verdadeiramente paralelas para problemas. Na maioria das vezes, porém, se é melhor ter soluções baseadas em conjunto, acho que a velocidade da RAM e do disco rígido é o maior gargalo, e o segundo parece ser o seu caso. (Onde a ideia do SSD acima seria útil)
Sem nenhuma estatística real 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 precisem de um histórico) e colocando muito mais dinheiro em seus discos rígidos do que os da CPU. O servidor SQL é muito bom em fazer consultas paralelas (se elas forem escritas para isso), mas se você estiver pesado em gravações, seu disco rígido é o verdadeiro gargalo.