O foco principal deste site de blog é o desempenho em um ambiente SQL Server. Pode-se argumentar que o desempenho começa com o design do banco de dados e do aplicativo. Mas você também pode argumentar que ter os recursos certos disponíveis é essencial para um bom desempenho. Para toda a discussão sobre os recursos certos (qual modelo de CPU, quanta memória, que tipo de armazenamento), às vezes negligenciamos o ato de planejamento de capacidade:usando os dados que temos para tomar decisões informadas sobre o que precisamos . O planejamento de capacidade não é apenas descobrir quanto espaço em disco precisamos, mas também envolve os recursos que uma instância do SQL Server deve ter disponíveis para lidar com a carga de trabalho.
Novo ou existente?
O planejamento de capacidade para uma nova solução é realmente complicado. Você precisa apresentar estimativas sobre a carga de trabalho com base nas informações coletadas da empresa. Isso significa que você precisa fazer perguntas difíceis sobre a quantidade de dados que eles esperam no primeiro mês, nos primeiros seis meses e no primeiro ano. Quando uma nova solução está chegando, isso geralmente é a ÚLTIMA coisa em que a empresa está pensando, então muitas vezes você obterá respostas vagas. No caso de uma nova solução, você realmente precisa fazer um melhor esforço de adivinhação. Não puxe o cabelo tentando obter números exatos.
Se a solução for de um fornecedor, você deverá solicitar ao fornecedor recomendações de planejamento sobre o espaço necessário e os recursos necessários. Eu admito, eles podem não ter esses dados, mas você não recebe o que não pede. Não custa nada tentar.
[Bônus:se o fornecedor não tiver nenhuma informação para fornecer, não seria útil se, após o sistema estar funcionando por alguns meses, você enviasse seus dados... como o hardware que você possui , e como é a carga de trabalho? Não precisa ser um artigo de 20 páginas, mas o feedback pode levá-los a serem mais proativos daqui para frente.]
Em termos de uma solução existente, se você está tendo um problema de desempenho ou deseja atualizar o hardware, convém capturar informações sobre o ambiente atual para planejar um novo.
Armazenamento
Planejando o valor de armazenamento necessário é bastante simples, requer apenas algum planejamento antecipado. Em meus artigos de verificação de integridade proativa do SQL Server, discuto o monitoramento do espaço em disco e incluo uma consulta para capturar informações do arquivo. Essa consulta captura o tamanho dos arquivos de banco de dados para a instância, bem como o espaço usado. É imperativo acompanhar esses dados ao longo do tempo, e isso não significa algumas semanas. Você quer ver como os arquivos mudam ao longo dos meses, possivelmente por até um ou dois anos, porque os padrões de uso de um aplicativo podem mudar. Essas informações são fáceis de capturar, requerem pouco espaço para armazenar e são inestimáveis para se ter como referência ao adquirir armazenamento. Se você puder fornecer dados quantitativos sobre o crescimento do sistema, terá uma chance muito maior de obter o espaço de que precisa antecipadamente, em vez de solicitar mais tarde. E quando você está pedindo espaço, certifique-se de incluir tempdb em seus cálculos.
Recursos de hardware
CPU
Otimizar o desempenho da sua CPU não é apenas o número de CPUs que você possui, você também deve considerar o modelo e a carga de trabalho (por exemplo, data warehouse com grandes consultas paralelas versus OLTP com consultas seriais). Com essas informações e uma pequena ajuda de Glenn, você pode determinar o melhor processador para o seu servidor. Não se esqueça de considerar os custos e limitações de licenciamento com base na sua edição do SQL Server!
Memória
A memória é relativamente barata e é nossa recomendação sempre comprar a quantidade máxima de memória que um servidor pode conter. A leitura de dados da memória é significativamente mais rápida do que a leitura do disco, portanto, quanto mais dados caberem na memória, melhor. Observe que o banco de dados inteiro não tem para caber na memória. Você só precisa que o conjunto de dados de trabalho caiba na memória. Considere um banco de dados de 2 TB. É improvável que, em um cenário OLTP, todos os 2 TB sejam acessados todos os dias. Normalmente, apenas os dados recentes são acessados – talvez apenas os últimos 30 ou 60 dias. Esses são os dados que precisam caber na memória. Mas é claro que raramente vemos um ambiente OLTP puro, geralmente é um ambiente misto porque os usuários gostam de executar relatórios em grandes conjuntos de dados e não há data warehouse ou cópia de relatórios do banco de dados, então eles têm para executar os relatórios em relação à produção. Isso complica o requisito de memória. Agora, às vezes você precisa desses dados mais antigos na memória, mas às vezes não. É importante entender a carga de trabalho; que tipos de consultas estão sendo executadas no banco de dados?
Se você estiver usando o Standard Edition, verifique se tem mais memória no servidor do que a memória máxima suportada. Por exemplo, com o SQL Server 2014 e superior, na Standard Edition, a quantidade máxima de memória que você pode alocar ao pool de buffers (por meio da configuração de memória máxima do servidor) é 128 GB. Portanto, você deseja ter mais memória no servidor (por exemplo, 160 GB) para poder definir a memória máxima do servidor no valor mais alto possível de 128 GB e ainda ter memória disponível para o sistema operacional e outros processos do SQL Server. Além disso, com o SQL Server 2016 SP1 Standard Edition, você pode usar o OLTP na memória, com um limite de 32 GB por banco de dados. Isso está acima do valor máximo de memória do servidor, portanto, se você planeja usar esse recurso, compre memória de acordo.
Armazenamento
Quando falamos sobre requisitos de desempenho para armazenamento, você costuma ouvir as pessoas falarem sobre IOPS (operações de entrada/saída por segundo). Na verdade, este artigo foi inspirado por uma pergunta de um espectador que assistiu ao meu curso Pluralsight sobre Benchmarking e Baselining. A pergunta era:“Como você correlaciona os contadores do Monitor de Desempenho para leituras e gravações por segundo às conexões do usuário para estimar o número de E/S por usuário?” As leituras e gravações por segundo são as operações de entrada/saída, portanto, temos esses dados disponíveis por meio do PerfMon no nível da instância, e é isso que você usa para definir os requisitos de IOPS para uma instância.
No entanto, se você sabe ler e escrever e conexões de usuário, então você pode fazer algumas contas e descobrir IOPS por usuário. Isso é útil se você planeja expandir a solução e adicionar mais usuários. Você quer ter certeza de que a solução será dimensionada, e uma opção que você tem é pegar seu IOPS calculado por usuário, com base no número X de usuários e, em seguida, estimar o IOPS da instância para o número Y de usuários. Agora, fazemos muitas suposições com esse cálculo. Assumimos que a maneira como as novas conexões usam o sistema é a mesma de hoje – isso pode ou não ser o caso no final, você não saberá até que o sistema esteja instalado. Quando você entende esse valor (leituras + gravações / conexões do usuário =IOPS médio por usuário), sabe como estimar o IOPS para uma solução com base nas conexões do usuário previstas.
Em seguida, você leva essas informações ao responsável pelo armazenamento para discutir as possíveis configurações disponíveis. Você pode calcular o IOPS máximo para uma configuração de disco, desde que tenha informações sobre os discos (por exemplo, o número de discos, a velocidade, o tamanho e a configuração RAID). Você pode testar a taxa de transferência de E/S para uma unidade usando o CrystalDiskMark, embora isso possa não ser possível se o armazenamento não tiver sido decidido. No entanto, quando estiver em vigor, você deve passar por esse teste para garantir que o IOPS de uma determinada unidade possa atender à carga de trabalho esperada.
IOPS são apenas uma maneira de analisar o desempenho do armazenamento. Entenda que esses dados informam quanto IO está ocorrendo e, idealmente, se você conhece o IOPS e tem o armazenamento para atender aos requisitos, a latência deve ser mínima. Mas, a latência é o que afeta o desempenho. Para determinar qual latência existe, você precisará usar uma ferramenta como DiskSpd para comparar o armazenamento. Glenn tem um ótimo artigo que explica como analisar o desempenho de IO e, em seguida, outro artigo sobre como usar o DiskSpd para testá-lo e entender a latência. É altamente recomendável revisar os dois artigos se você não tiver analisado o armazenamento e o desempenho anteriormente.
Conclusão
O planejamento de capacidade é mais do que apenas saber quanto espaço você precisa para arquivos de banco de dados. Você precisa entender a carga de trabalho e o que ela requer em termos de recursos de CPU, memória e disco. Para fazer isso, você precisa de dados... o que significa que você precisa capturar linhas de base. Minha primeira sessão na comunidade do SQL Server foi em dezembro de 2010 e foi sobre o tópico de linhas de base. Seis anos depois, ainda estou falando sobre a importância deles, e ainda ouço das pessoas que elas não têm esses números. Se você deseja fazer um planejamento de capacidade inteligente e direcionado, precisa coletar os dados apropriados... caso contrário, você está apenas supondo.
