Um dos gargalos de desempenho mais comuns que vejo como consultor é o desempenho inadequado do subsistema de armazenamento. Há vários motivos para o baixo desempenho do armazenamento, mas medi-lo e entender o que precisa ser medido e monitorado é sempre um exercício útil.
Na verdade, existem três métricas principais que são mais importantes quando se trata de medir o desempenho do subsistema de E/S:
Latência
A primeira métrica é a latência, que é simplesmente o tempo que uma E/S leva para ser concluída. Isso geralmente é chamado de tempo de resposta ou tempo de serviço. A medição começa quando o sistema operacional envia uma solicitação à unidade (ou ao controlador de disco) e termina quando a unidade conclui o processamento da solicitação. As leituras são concluídas quando o sistema operacional recebe os dados, enquanto as gravações são concluídas quando a unidade informa ao sistema operacional que recebeu os dados.
Para gravações, os dados ainda podem estar em um cache DRAM na unidade ou no controlador de disco, dependendo da política de cache e do hardware. O cache de write-back é muito mais rápido do que o cache de write-through, mas requer um backup de bateria para o controlador de disco. Para uso do SQL Server, você deseja certificar-se de que está usando o cache de write-back em vez do cache de write-through, se possível. Você também deseja certificar-se de que o cache de disco do hardware esteja realmente ativado, pois algumas ferramentas de gerenciamento de disco do fornecedor o desativam por padrão.
Operações de entrada/saída por segundo (IOPS)
A segunda métrica é Operações de entrada/saída por segundo (IOPS). Essa métrica está diretamente relacionada à latência. Por exemplo, uma latência constante de 1 ms significa que uma unidade pode processar 1.000 E/S por segundo com uma profundidade de fila de 1. À medida que mais E/S são adicionadas à fila, a latência aumenta. Uma das principais vantagens do armazenamento flash é que ele pode ler/gravar em vários canais NAND em paralelo, juntamente com o fato de que não há partes móveis eletromecânicas para diminuir o acesso ao disco. Na verdade, o IOPS é igual à profundidade da fila dividida pela latência, e o IOPS por si só não considera o tamanho da transferência para uma transferência de disco individual. Você pode converter IOPS em MB/s e MB/s em latência, desde que saiba a profundidade da fila e o tamanho da transferência.
Taxa de transferência sequencial
A taxa de transferência sequencial é a taxa de transferência de dados, normalmente medida em megabytes por segundo (MB/s) ou gigabytes por segundo (GB/s). Sua métrica de taxa de transferência sequencial em MB/s é igual ao IOPS vezes o tamanho da transferência. Por exemplo, 556 MB/s é igual a 135.759 IOPS vezes um tamanho de transferência de 4.096 bytes, enquanto 135.759 IOPS vezes um tamanho de transferência de 8.192 bytes seria 1.112 MB/s de taxa de transferência sequencial. Apesar de sua importância diária para o SQL Server, a taxa de transferência de disco sequencial geralmente é prejudicada no armazenamento corporativo, tanto por fornecedores de armazenamento quanto por administradores de armazenamento. Na verdade, também é bastante comum ver os discos magnéticos reais em um gabinete de armazenamento de conexão direta (DAS) ou em um dispositivo de rede de área de armazenamento (SAN) tão ocupados que não podem fornecer sua taxa de transferência sequencial nominal total.
A taxa de transferência sequencial é fundamental para muitas atividades comuns do servidor de banco de dados, incluindo backups e restaurações completos de banco de dados, criação e reconstrução de índice e grandes varreduras de leitura sequencial do tipo data warehouse (quando seus dados não se encaixam no pool de buffers do SQL Server). Uma meta de desempenho que eu gosto de atingir em novas compilações de servidor de banco de dados é ter pelo menos 1 GB/s de taxa de transferência sequencial para cada letra de unidade ou ponto de montagem. Ter esse nível de desempenho (ou melhor) facilita muito sua vida como profissional de banco de dados. Isso torna muitas de suas tarefas comuns de banco de dados muito mais rápidas e também oferece a liberdade de fazer ajustes de índice mais frequentes quando você pode criar um índice em uma tabela grande em segundos ou minutos, em vez de horas.
Métricas de carga de trabalho de E/S do SQL Server
Quando se trata de SQL Server e desempenho de E/S, há várias coisas que você deve medir e monitorar ao longo do tempo. Você deve saber a proporção de leitura versus gravação para sua carga de trabalho para todos os seus arquivos de banco de dados do usuário e para tempdb. As proporções serão diferentes para diferentes tipos de arquivos e cargas de trabalho do SQL Server. Você pode usar minhas consultas de diagnóstico DMV para determinar isso e também pode usar a exibição de atividade de disco no SQL Sentry Performance Advisor para obter facilmente uma visão mais completa da atividade do disco, de uma imagem geral de alto nível, até o fim para arquivos individuais:
SQL Sentry Performance Advisor:atividade de disco Você também deve medir as taxas de E/S típicas para IOPS e taxa de transferência sequencial. No Monitor de Desempenho do Windows (PerfMon), as leituras/s e as gravações/s mostram IOPS, enquanto os bytes de leitura do disco/s e os bytes de gravação do disco/s representam a taxa de transferência sequencial. Você deve usar o PerfMon para medir a média de segundos/leitura de disco e média de segundos/gravação de disco, que é a latência de leitura e gravação no nível do disco. Por fim, você pode usar minhas consultas de diagnóstico DMV para medir a latência média de leitura e gravação em nível de arquivo para todos os arquivos de banco de dados do usuário, bem como para tempdb.
Métodos para medir o desempenho de E/S
Você pode usar a seção Disco no Windows Resource Monitor para obter uma exibição rápida e em tempo real de algumas métricas de disco importantes para todos os arquivos de banco de dados do SQL Server. Indo mais fundo, você pode usar o PerfMon para medir e monitorar os contadores de desempenho críticos que mencionei anteriormente. Antes de entrar em produção com um novo servidor de banco de dados, você deve fazer alguns testes de benchmark de disco para determinar que tipo de desempenho seu subsistema de E/S pode realmente fornecer. Na verdade, isso não é tão difícil ou demorado (se você usar as ferramentas certas), mas geralmente é esquecido quando um novo servidor de banco de dados é provisionado e testado.
O primeiro benchmark de disco que você deve sempre executar é o CrystalDiskMark 4.0, que foi recentemente reescrito para usar o relativamente novo programa de benchmark de disco Microsoft DiskSpd. A interface de usuário do CDM 4.0 permite que você escolha uma variedade maior de tamanhos de arquivos de teste e também permite que você escolha a profundidade da fila e o número de threads para as execuções de teste. Isso permite que você obtenha uma carga de trabalho de E/S mais semelhante a um servidor e também permite que você esforce mais adequadamente os dispositivos de armazenamento flash NVMe mais recentes que podem lidar com profundidades de fila superiores a 32.
Resultados do CrystalDiskMark 4.03 com QD =32 e threads =1 
Figura 2:Resultados do CrystalDiskMark 4.03 com QD =32 e threads =4 Ao contrário das versões anteriores do CDM, as duas linhas mais relevantes para uso do SQL Server estão no meio da exibição dos resultados. São as leituras e gravações aleatórias de 4K com uma profundidade de fila alta (32 por padrão) e as leituras e gravações sequenciais. Depois de fazer alguns testes de benchmark de armazenamento com o CrystalDiskMark 4.0, você deve fazer alguns testes mais exaustivos com o Microsoft DiskSpd. Em um artigo futuro, abordarei como usar o DiskSpd para fazer testes mais completos para o SQL Server.
