Temos um aplicativo que consulta um banco de dados SQL periodicamente ao longo do dia. Existem períodos de zero ou apenas atividade leve, intercalados com solicitações individuais para quantidades relativamente grandes de dados. Quando essas solicitações chegam, o objetivo principal é entregar 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 (usuários diferentes, trabalhando em diferentes partes dos dados).
Para um sistema que apresenta uso relativamente estável, ouvi a regra geral para observar o comprimento da fila de 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 esse sistema? O comprimento da fila do disco é um indicador confiável ao lidar com consultas individuais e intermitentes? Existem outras métricas que devo considerar?
fonte
Respostas:
A métrica principal que sempre considerei para E / S no SQL Server não é a IOPs ou o comprimento da fila de disco, mas a taxa de transferência do disco (s / leituras e s / gravações). No geral, os bancos de dados não são sobre quantas operações você pode lançar em um disco, mas com que rapidez essas operações são concluídas. A regra geral é ter menos de 20ms / operação (embora menor seja sempre melhor). Mais detalhes podem ser encontrados neste artigo .
O comprimento da fila de disco é um status falso e não é mais relevante. O problema é que o valor mede a fila de uma única unidade, mas agora que vivemos na era dos RAIDs, SANs e outros armazenamentos distribuídos, não há como traduzir adequadamente esse valor para um número significativo. Um excelente 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 auge. Quantas transações e quanto é armazenado em cache? A menos que você saiba e tenha medido essas medidas, é realmente difícil julgar. Você pode criar cargas de trabalho e usar ferramentas como o 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 garantirá o desempenho de IO 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 área específica de armazenamento (consulte o problema Noisy Neighbour ).
Minha recomendação seria alocar o máximo de memória possível. O SQL Server apenas enviará as coisas para fora da memória se estiver sob pressão e espaço no buffer pool (com base no LRU-K). Portanto, se seu buffer pool pode armazenar a maior parte do banco de dados na memória, você pode mitigar parte do desempenho explosivo. Além disso, considere táticas que podem manter os objetos de cache "quentes". Por fim, fique de olho no SQL 2014 e no novo recurso Hekaton .
fonte