O SQL Server encontrou ocorrências de solicitações de E / S levando mais de 15 segundos

No SQL Server de produção, temos a seguinte configuração:

3 servidores Dell PowerEdge R630, combinados no grupo de disponibilidade Todos os 3 estão conectados a uma única unidade de armazenamento Dell SAN, que é uma matriz RAID

De tempos em tempos, no PRIMARY, vemos mensagens semelhantes às abaixo:

O SQL Server encontrou 11 ocorrências de solicitações de E / S que demoram mais de 15 segundos para serem concluídas no arquivo [F: \ Data \ MyDatabase.mdf] no ID de banco de dados 8.
O identificador de arquivo do SO é 0x0000000000001FBC.
O deslocamento da E / S longa mais recente é: 0x000004295d0000.
A duração da E / S longa é: 37397 ms.

Somos iniciantes na solução de problemas de desempenho

Quais são as maneiras ou práticas recomendadas mais comuns para solucionar esse problema específico relacionado ao armazenamento? Quais contadores de desempenho, ferramentas, monitores, aplicativos etc. devem ser usados ​​para reduzir a causa raiz dessas mensagens? Pode haver um evento estendido que possa ajudar ou algum tipo de auditoria / registro?

Temos uma configuração semelhante e encontramos essas mensagens recentemente nos logs. Estamos usando uma SAN DELL Compellent. Aqui estão algumas coisas para verificar ao receber essas mensagens que nos ajudaram a encontrar uma solução

• Revise os contadores de desempenho do Windows para os discos apontados pelas mensagens de aviso, especificamente:
  • Média de disco tempo de leitura
  • Média de disco tempo de gravação
  • Bytes de leitura de disco / s
  • Bytes de gravação em disco / s
  • Transferências de disco / s
  • Média comprimento da fila de disco
• O acima são médias. Se você tiver muitos arquivos de banco de dados em uma unidade, essas médias podem distorcer o resultado e mascarar um gargalo em arquivos específicos do banco de dados. Confira esta consulta de Paul S. Randal, que retorna a latência média para cada arquivo do dmv sys.dm_io_virtual_file_stats. No nosso caso, a latência média relatada era aceitável, mas por baixo das capas havia muitos arquivos com latência média> 200 ms.
• Verifique os horários. Existe algum padrão? Isso acontece com mais frequência a uma hora da noite? Nesse caso, verifique se algum trabalho de manutenção está em execução naquele momento ou se há alguma atividade agendada que possa aumentar a atividade do disco e expor um gargalo no subsistema de E / S.
• Verifique se há erros no visualizador de eventos do Windows. Se o seu switch ou SAN estiver sobrecarregado ou não estiver configurado corretamente para o seu aplicativo, você poderá encontrar algumas mensagens neste log, e é bom levar essas informações ao administrador da SAN. No nosso caso, estávamos recebendo erros de conexão iSCSI frequentemente ao longo do dia, sugerindo o problema.
• Revise seu código do SQL Server. Ao receber essas mensagens, você não deve pensar imediatamente que é um problema do subsistema de E / S e passá-lo ao administrador da SAN. Você precisa fazer sua parte e revisar o banco de dados. Você tem consultas realmente ruins sendo executadas, muitas vezes produzindo toneladas de dados? Indexação ruim? Gravações excessivas no log de transações? Você pode usar algumas consultas de código aberto para obter uma verificação de integridade em seu banco de dados; um exemplo para verificar a aparência do seu plano de consulta é sp_blitzCache
• Não os ignore. Hoje você pode recebê-los algumas vezes por dia ... e vários meses depois, quando sua carga de trabalho aumenta e você se esquece de monitorá-los, eles começam a aumentar. O recebimento de muitas dessas mensagens pode impedir o SQL Server de acessar um determinado arquivo e, se for tempdb , isso não é bom. No nosso caso, ficou tão ruim que o SQL Server se desligou.

Nossa solução foi atualizar nosso switch para um switch SAN. Sim, esses são todos os pontos a serem abordados no SQL Server. O que nos levou a descobrir que era a opção era que estávamos recebendo cerca de 1500 erros de desconexão iSCSI pdu no visualizador de eventos de aplicativos do Windows no SQL Server todos os dias. Isso levou à investigação de nossos administradores da SAN sobre o switch.

Imediatamente após a atualização, os erros do iSCSI desapareceram e a latência média caiu para cerca de 50 ms para todos os arquivos, e isso se correlacionou com o melhor desempenho do aplicativo. Com esses pontos em mente, espero que você possa encontrar sua solução.

Isso é muito menos um problema de disco e muito mais frequentemente um problema de rede. Você sabe, o N na SAN?

Se você for à sua equipe de SAN e começar a falar sobre os discos serem lentos, eles mostrarão um gráfico sofisticado com latência de 0 milissegundos e apontarão um grampeador para você.

Em vez disso, pergunte a eles sobre o caminho da rede para a SAN. Obtenha velocidades, se tiver vários caminhos, etc. Obtenha números sobre as velocidades que você deveria estar vendo. Pergunte se eles têm referências de quando os servidores foram configurados.

Em seguida, você pode usar o Crystal Disk Mark ou diskpd para validar essas velocidades. Se eles não se alinharem, novamente, é mais provável que a rede.

Você também deve procurar no log de erros por mensagens que contenham "FlushCache" e "saturação", porque elas também podem ser sinais de contenção de rede.

Uma coisa que você pode fazer para evitar essas coisas como DBA é garantir que sua manutenção e quaisquer outras tarefas pesadas em dados (como ETL) não ocorram ao mesmo tempo. Definitivamente, isso pode pressionar bastante as redes de armazenamento.

Você também pode consultar as respostas aqui para obter mais sugestões: Ponto de verificação lento e avisos de E / S de 15 segundos no armazenamento flash

Eu escrevi sobre um tópico semelhante aqui: Do servidor à SAN

Por que armazenar os dados em uma SAN? Qual é o objetivo? Todo o desempenho do banco de dados está vinculado à E / S de disco e você está usando 3 servidores com apenas um dispositivo para a E / S por trás deles. Isso não faz sentido ... e infelizmente é tão comum.

Passo minha vida encontrando plataformas de hardware mal projetadas, onde as pessoas apenas tentam projetar um computador em grande escala. Toda a energia da CPU aqui, todos os discos ali ... espero que não exista algo como RAM remota. E o mais triste é que eles compensam a falta de eficiência desse design com enormes servidores que custam dez vezes mais do que deveriam. Eu vi $ 400k infra mais lento que um laptop de $ 1k.

Um software para servidor SQL é um software muito avançado, projetado para tirar proveito de todos os bits de hardware, núcleos da CPU, cache da CPU, TLB, RAM, controladores de disco, cache do disco rígido ... Eles quase incluem toda a lógica do sistema de arquivos. Eles são desenvolvidos em computadores comuns e comparados em sistemas de ponta. Portanto, um servidor SQL deve ter seus próprios discos. Instalá-los em uma SAN é como "emular" um computador, você perde todas as otimizações de desempenho. As SANs destinam-se ao armazenamento de backups, arquivos imutáveis ​​e arquivos aos quais você apenas anexa dados (logs).

Os administradores do datacenter tendem a colocar tudo o que podem nas SANs, pois dessa forma eles têm apenas um pool de armazenamento para gerenciar, é mais fácil do que cuidar do armazenamento em cada servidor. É uma opção "não quero fazer meu trabalho" e muito ruim, porque eles precisam lidar com problemas de desempenho e toda a empresa sofre com isso. Basta instalar o software no hardware para o qual foi projetado. Mantenha simples. Cuidar da largura de banda de E / S, sobrecarga do cache e da alternância de contexto, tremulação de recursos (acontece quando o recurso é compartilhado). Você acabará mantendo 1/10 dos dispositivos com a mesma potência de saída bruta, economizando muitas dores de cabeça à equipe de operações, obtendo um desempenho que deixa seus usuários finais felizes e mais produtivos, torna sua empresa um lugar melhor para trabalhar e economize muita energia (o planeta agradecerá).

Você disse nos comentários que está pensando em colocar o SSD no seu servidor. Você não reconhecerá sua configuração com SSDs dedicados; em comparação com uma SAN, obterá algo como uma melhoria de 500x, mesmo com arquivos de log de dados e transações na mesma unidade. Um SQL Server de última geração teria um SSD separado rápido para dados e log de transações em diferentes canais de controladores de hardware (a maioria das placas-mãe de servidores possui vários). Mas comparado à sua configuração atual, estamos falando de ficção científica lá. Apenas tente o SSD.

Ok, para qualquer pessoa interessada,

Resolvemos o problema na questão há alguns meses, simplesmente instalando unidades SSD conectadas diretamente em cada um dos 3 servidores e movendo dados de banco de dados e arquivos de log da SAN para essas unidades SSD

Aqui está um resumo do que eu fiz para pesquisar sobre esse problema (usando recomendações de todos os posts desta pergunta), antes de decidirmos instalar unidades SSD:

1) começou a coletar contadores PerfMon para as seguintes unidades nos 3 servidores:

Disk F:é um disco lógico baseado na SAN, contém arquivos de dados MDF
Disk I:é um disco lógico baseado na SAN, contém arquivos de log LDF,
Disk T:é conectado diretamente ao SSD, dedicado exclusivamente ao tempDB

A figura abaixo mostra os valores médios coletados por um período de 2 semanas

Disk I: (LDF)tem uma E / S tão pequena e a latência é muito baixa, portanto, o Disco I: pode ser ignorado
Você pode ver que a Disk T: (TempDB)E / S é maior em comparação com a E / S Disk F: (MDF)e tem uma latência muito melhor ao mesmo tempo - 0 ms

Obviamente, há algo errado com o Disco F: onde os arquivos de dados residem, ele possui alta Latência e Fila Média de Gravação de Disco, apesar da baixa IO

2) Latência verificada para bancos de dados individuais usando a consulta deste site

https://www.brentozar.com/blitz/slow-storage-reads-writes/

Poucos bancos de dados ativos no servidor Primário tinham latência de leitura de 150-250 ms e latência de gravação de 150-450 ms
O interessante é que os arquivos de banco de dados mestre e msdb tinham latência de leitura de até 90 ms, o que é suspeito, devido ao tamanho pequeno dos dados e baixo IO - outra indicação de que algo está errado com a SAN

3) Não houve horários específicos

Durante o qual as mensagens "O SQL Server encontrou ocorrências ..."
foram exibidas Não havia manutenção ou ETL pesado em disco em execução quando essas mensagens foram registradas

4) Visualizador de Eventos do Windows

Não mostrou outras entradas que sugerissem o problema, exceto "O SQL Server encontrou ocorrências ..."

5) Começou a verificar as 10 principais consultas

De sp_BlitzCache (CPU, leituras, etc.) e omitindo sempre que possível
Não há consultas pesadas de super IO que gerem toneladas de dados e afetam fortemente o armazenamento, embora a
indexação em bancos de dados seja boa, eu mantenho isso

6) Não temos equipe SAN

Temos apenas 1 administrador de sistemas que ajuda no
caminho de rede da ocasião para a SAN - ele é de caminhos múltiplos, cada um dos 3 servidores possui 2 cabos de rede que levam aos comutadores e depois à SAN, e deve ser de 1 Gigabyte / s

7) Não houve resultados no CrystalDiskMark

Ou qualquer outro resultado de teste de benchmark de quando os servidores foram configurados, portanto, não sei quais devem ser as velocidades , e não é possível fazer benchmark neste momento para ver quais são as velocidades atualmente, pois isso afetaria a produção.

8) Configuração da sessão de eventos estendidos no evento do ponto de verificação para o banco de dados em questão

A sessão XE ajudou a descobrir que, durante as mensagens "O SQL Server encontrou ocorrências ...", o ponto de verificação aconteceu muito lento (até 90 segundos)

9) Log de erro do SQL Server

Contém entradas "FlushCache" "Saturação"
Elas devem aparecer quando o tempo do ponto de verificação para um determinado banco de dados exceder as configurações do intervalo de recuperação

Os detalhes mostraram que a quantidade de dados que o ponto de verificação está tentando liberar é pequena e está demorando muito para ser concluída, e a velocidade geral é de cerca de 0,25 MB / s ... estranho

10) Finalmente, esta imagem mostra a tabela de solução de problemas de armazenamento:

Parece que simplesmente temos um "Problema de hardware: - Trabalhe com o administrador do sistema / fornecedor de hardware para corrigir qualquer configuração incorreta da SAN, drivers antigos / defeituosos, controladores, firmware etc."

Em outra pergunta "Ponto de verificação lento ..." Ponto de verificação lento e avisos de E / S de 15 segundos no armazenamento flash Sean tinha uma lista muito boa de quais itens devem ser verificados no nível de hardware e software para solucionar problemas

Nosso sysadmin não pôde verificar todas as coisas da lista; portanto, simplesmente escolhemos lançar algum hardware para esse problema - não foi nada caro

Resolução:

Pedimos unidades SSD de 1 TB e instalamos diretamente em servidores

Como temos grupos de disponibilidade, os arquivos de dados do banco de dados migraram da SAN para o SSD nas réplicas secundárias e, em seguida, efetuaram failover e os arquivos migrados no antigo primário. Isso permitiu um tempo de inatividade total mínimo - menos de 1 minuto

Agora, cada servidor possui uma cópia local dos dados do banco de dados e os backups completos / diff / log são feitos na SAN mencionada.
Não há mais mensagens "O SQL Server encontrou ocorrências ..." nos logs do Windows Event Viewer e desempenho de backups, verificações de integridade, recriações de índice, consultas etc. aumentou significativamente

Quanto desempenho em termos de latência de IO melhorou desde a migração dos arquivos de banco de dados para o SSD?

Para avaliar o impacto, o desempenho usado do Windows Performance Monitor registra 2 semanas antes da migração e 4 semanas após a migração:

Abaixo também está a comparação de estatísticas de latência no nível do banco de dados (usadas estatísticas de arquivos virtuais capturados do SQL Server antes e após a migração)

Sumário

A migração da SAN para SSDs locais conectados diretamente valeu a pena.
Ela teve um grande impacto na latência do armazenamento e melhorou muito mais de 90% em média (especialmente operações WRITE), e não temos mais picos de 20 a 50 segundos na IO

A mudança para o SSD local resolveu não apenas os problemas de desempenho de armazenamento, mas também a segurança dos dados que me preocupavam (se a SAN falhar, os três servidores perderão os dados ao mesmo tempo)