Temos um aplicativo que consulta um banco de dados SQL periodicamente ao longo do dia. Há períodos de atividade zero ou apenas leve, intercalados com solicitações individuais de quantidades relativamente grandes de dados. Quando essas solicitações chegam, o objetivo principal é fornecer os dados rapidamente, e o objetivo secundário é fazer isso de maneira econômica. Devido à natureza do aplicativo, é bastante improvável que os dados/índices tenham sido armazenados em cache na RAM da consulta anterior (diferentes usuários, trabalhando em diferentes partes dos dados).
Para um sistema que experimenta um uso relativamente estável, ouvi a regra geral de observar o comprimento da fila do disco e manter esse número relativamente pequeno. Isso será executado especificamente na AWS, onde vi a regra geral de que um comprimento de fila de disco de 1 por 100 IOPS é razoável.
Como posso estimar os requisitos de IO para tal sistema? O comprimento da fila de disco é um indicador confiável ao lidar com consultas individuais em rajadas? Existem outras métricas que devo considerar?
A métrica principal que sempre considerei para IO no SQL Server não é IOPs ou comprimento da fila de disco, mas taxa de transferência de disco (seg/leituras e seg/gravações). No geral, os bancos de dados não tratam de quantas operações você pode executar em um disco, mas da rapidez com que essas operações são concluídas. A regra geral é ter menos de 20 ms/operação (embora menor seja sempre melhor). Mais detalhes podem ser encontrados neste artigo .
Disk Queue Length é uma estatística falsa e não é mais relevante. O problema é que o valor mede a fila para uma única unidade, mas agora que vivemos em uma era de RAIDs, SANs e outros armazenamentos distribuídos, não há como traduzir corretamente esse valor em um número significativo. Um ótimo ponto de partida para as métricas de desempenho é este pôster da Quest/Dell que fornece muitas coisas e explicações sobre por que elas são importantes ou não. Você não precisa usar todos eles, mas eles são um começo.
Para testar seu IO, você precisa entender sua carga de trabalho no pico. Quantas transações e quanto é armazenado em cache? A menos que você conheça e tenha medido isso, é realmente difícil julgar. Você pode criar cargas de trabalho e usar ferramentas como SQLIO para testar seu armazenamento, mas precisará de padrões de carga de trabalho para criar um teste adequado.
Por fim, uma observação sobre a AWS: que eu saiba, a Amazon não garante o desempenho de E/S na AWS. Isso ocorre principalmente porque o armazenamento é um recurso compartilhado massivo e é impossível avaliar os padrões de você e seus vizinhos em uma determinada área de armazenamento (consulte o problema Noisy Neighbor ).
Minha recomendação seria alocar o máximo de memória possível. O SQL Server só enviará coisas para fora da memória se estiver sob pressão e espaço no buffer pool (baseado em LRU-K). Portanto, se o pool de buffers puder armazenar a maior parte do banco de dados na memória, você poderá atenuar parte do desempenho intermitente. Além disso, considere as táticas que podem manter os objetos de cache "quentes". Por fim, fique de olho no SQL 2014 e no novo recurso Hekaton .