Uma das coisas que são simultaneamente ótimas e horríveis na Internet é que, uma vez que algo é postado no éter, basicamente nunca desaparece. (Algum dia, os políticos perceberão isso. Podemos verificar facilmente sua consistência.) Devido à longevidade do conteúdo postado na Internet, muitos tópicos de ajuste de desempenho se tornam "zumbis". Nós atiramos neles, mas eles continuam voltando!
Em outras palavras, essas recomendações antigas eram uma prática recomendada sugerida há muito tempo, para uma versão específica do SQL Server, mas agora são inadequadas para a versão mais recente. Não é incomum para mim, ao falar em uma conferência, encontrar alguém que ainda se apega a configurações e técnicas que não são uma boa prática desde os dias do SQL Server 2000. O Guia de operações do SQL Server 2000 sobre capacidade/armazenamento contém muitos " recomendações de melhores práticas" que eram muito específicas da versão e não se aplicam mais hoje. Então aqui está um exemplo. O
% Disk Time e Disk Queue Length Os contadores PerfMon foram altamente recomendados como indicadores-chave de desempenho de E/S. O SQL Server lança muita E/S nos discos usando dispersão/reunir para maximizar a utilização do subsistema de E/S baseado em disco. Essa abordagem leva a rajadas curtas de profundidades de fila longas durante pontos de verificação e leituras antecipadas para uma instância do SQL Server. Às vezes, a carga de trabalho do servidor é tal que seu disco não consegue acompanhar a E/S empurrada para ele e, quando isso acontece, você também verá longos comprimentos de fila. O cenário de rajada curta não é um problema. O cenário de aumento do comprimento da fila geralmente é um problema. Então isso é uma boa prática? Em uma palavra, nem tanto.
Esses contadores ainda podem ser úteis em uma instância do SQL Server que tenha apenas um disco rígido (embora isso seja extremamente raro nos dias de hoje). Por quê?
O contador PerfMon
% Disk Time é uma métrica de desempenho falsa por vários motivos. Ele não leva em consideração solicitações de E/S assíncronas. Ele não pode dizer qual pode ser o perfil de desempenho real de um conjunto RAID subjacente, pois eles contêm várias unidades de disco. O contador PerfMon Disk Queue Length também é praticamente inútil, exceto em SQL Servers com um único disco físico, porque o cache do controlador de disco rígido ofusca quantas operações de E/S estão realmente pendentes na fila ou não. Na verdade, alguns discos rígidos também têm minúsculos caches de gravação, o que atrapalha ainda mais a questão de saber se a E/S está realmente enfileirada, em um cache em algum lugar entre o sistema operacional e o disco, ou finalmente fez todo o caminho para o CMOS no disco. Melhores contadores de desempenho de E/S
Em vez de usar esses contadores PerfMon, use o
Avg Disk Reads/sec , Avg Disk Writes/sec e Avg Disk Transfers/sec para rastrear o desempenho dos subsistemas de disco. Esses contadores rastreiam o número médio de E/Ss de leitura, E/Ss de gravação e E/Ss combinadas de leitura e gravação que ocorreram no último segundo. Ocasionalmente, gosto de acompanhar as mesmas métricas por volume de dados em vez da taxa de operações de E/S. Portanto, para obter esses dados, experimente estes contadores PerfMon específicos de volume: Avg Disk Transfer Bytes/sec , Avg Disk Read Bytes/sec e Avg Disk Write Bytes/sec . Para desempenho de E/S do SQL Server, use exibições de gerenciamento dinâmico (DMV)
E, a menos que você esteja morando em uma caverna, certifique-se de usar as DMVs (Dynamic Management Views) do SQL Server para verificar o desempenho de E/S para versões recentes do SQL Server. Alguns dos meus DMVs favoritos para E/S incluem:
- sys.dm_os_wait_stats
- sys.dm_os_waiting_tasks
- sys.dm_os_performance_counters
- sys.dm_io_virtual_file_stats
- sys.dm_io_pending_io_requests
- sys.dm_db_index_operational_stats
- sys.dm_db_index_usage_stats
Então, como você está acompanhando as métricas de desempenho de E/S? Quais você está usando?
Estou ansioso para ouvir de você de volta!
Aproveite,
-Kev
–Siga-me no Twitter!
