Liberação de Cache do SQL Server e E / S de Disco

Estamos ocupados testando um sistema OLTP que desenvolvemos no .NET 4.0 e executando o SQL Server 2008 R2 nas costas. O sistema usa filas do SQL Server Service Broker, que são de alto desempenho, mas estamos experimentando uma tendência peculiar durante o processamento.

O SQL Server processa solicitações a uma taxa empolgante por 1 minuto, seguido por ~ 20 segundos de maior atividade de gravação em disco. O gráfico a seguir ilustra o problema.

Yellow = Transactions per second
Blue   = Total CPU usage
Red    = Sqlsrv Disk Write Bytes/s
Green  = Sqlsrv Disk Read Bytes/s

Durante a solução de problemas, tentamos o seguinte sem nenhuma alteração significativa no padrão:

• Agente do SQL Server parado.
• Matou quase todos os outros processos em execução (sem A / V, SSMS, VS, Windows Explorer, etc.)
• Removidos todos os outros bancos de dados.
• Desativou todos os cronômetros de conversação (não usamos gatilhos).
• Afastado de uma abordagem orientada a fila de mensagens para um design de monitoramento de tabela simples / bruto.
• Usou cargas diferentes, de leves a pesadas.
• Corrigidos todos os impasses.

Parece que o SQL Server pode estar construindo seu cache e gravando-o em disco em intervalos específicos baseados em tempo, mas não consigo encontrar nada online para apoiar essa teoria.

Em seguida, pretendo mudar a solução para o nosso ambiente de teste dedicado para ver se consigo replicar o problema. Qualquer ajuda nesse ínterim seria muito apreciada.

Atualização 1 Conforme solicitado, a seguir, um gráfico que inclui as páginas de ponto de verificação / segundo , a expectativa de vida da página e alguns contadores de latência do disco.

Parece que o ponto de verificação (linha azul clara) é a causa do desempenho reduzido (linha amarela) que estamos observando. ^

A latência do disco permanece relativamente consistente durante o processamento e a expectativa de vida da página não parece ter nenhum efeito perceptível. Também ajustamos a quantidade de memória RAM disponível para o SQL Server, o que também não teve um grande efeito. Alterar o modelo de recuperação de SIMPLEpara FULLtambém fez pouca diferença.

Atualização 2 Alterando o "Intervalo de recuperação" da seguinte maneira, conseguimos reduzir o intervalo no qual os pontos de verificação ocorrem:

EXEC sp_configure 'show advanced options',1
GO 

RECONFIGURE
GO

EXEC sp_configure 'recovery interval', '30'
GO

RECONFIGURE 
GO

EXEC sp_configure 'show advanced options',0
GO
RECONFIGURE

Não tenho certeza se isso é uma prática ruim?

Outros já apontaram o culpado: o SQL Server acumula atualizações na memória (no pool de buffers) e as libera periodicamente (nos pontos de verificação). As duas opções sugeridas (-k e intervalo do ponto de verificação) são complementares:

• -k fará da causa o ponto de verificação para produzir solicitações de E / S menos agressivas e durará mais tempo
• diminuir o intervalo de recuperação fará com que o ponto de verificação inicie com mais frequência

Mas eu não respondi apenas para regurgitar os bons comentários que você recebeu até agora :)

Infelizmente, o que você está vendo é um comportamento muito típico do processamento em fila . Independentemente de você usar filas do Service Broker ou optar por usar tabelas como abordagens de filas , o sistema é muito propenso a esse tipo de comportamento. Isso ocorre porque o processamento baseado em filas é pesado, ainda mais pesado que o processamento OLTP. As primitivas de enfileiramento e desenfileiramento são operações de gravação e quase não há operações de leitura. Simplificando, o processamento da fila gerará mais gravações (= mais páginas sujas e mais log) em comparação com qualquer outra carga de trabalho, mesmo OLTP (ou seja, TPC-C como carga de trabalho).

Muito importante, as gravações de uma carga de trabalho de fila seguem o padrão de inserção / exclusão: todas as linhas inseridas são excluídas muito rapidamente. É importante distinguir de um padrão somente anexado de uma carga de trabalho de inserção pesada (ETL). Você está basicamente alimentando a tarefa de limpeza de fantasmas com uma refeição completa e pode facilmente superá-la. Pense no que isso significa:

• enfileirar é uma inserção, ele criará uma página suja
• desenfileirar é uma exclusão, ela suja a mesma página novamente (pode ter sorte e capturá-la antes do ponto de verificação, para evitar a descarga dupla, mas somente se tiver sorte)
• A limpeza de fantasmas limpará a página, tornando-a suja novamente

Sim, isso realmente significa que você pode escrever uma página três vezes em disco, em três solicitações de E / S diferentes, para cada mensagem processada (pior caso). E também significa que a IO aleatória dos pontos de verificação será realmente aleatória, pois o ponto de gravação da página será visitado por aqueles que movem as cabeças novamente entre dois pontos de verificação (compare com muitas cargas de trabalho OLTP tendem a agrupar as gravações em alguns 'pontos de acesso', não filas ...).

Então você tem esses três pontos de gravação, correndo para marcar a mesma página de novo e de novo. E isso é antes de considerarmos as divisões de páginas, que o processamento da fila também pode ser propenso devido à ordem das chaves de inserção. Em comparação, as cargas de trabalho OLTP 'típicas' têm uma taxa de leitura / gravação muito mais equilibrada e as gravações OLTP são distribuídas entre inserções / atualizações / exclusões, geralmente com atualizações (alterações de 'status') e inserções que representam a maior parte. As gravações de processamento de fila são inseridas / excluídas exclusivamente com, por definição, divisão 50/50.

Algumas consequências a seguir:

• O ponto de verificação se torna um problema muito quente (não é mais uma surpresa para você)
• Você verá uma fragmentação pesada (a fragmentação em si não importará muito, pois você não fará varreduras de intervalo, mas sua eficiência de E / S sofre e a limpeza de fantasmas tem mais a funcionar, diminuindo ainda mais a velocidade)
• O rendimento aleatório de IO do armazenamento de MDF será seu gargalo

Minha recomendação vem em três letras: S, S e D. Mova seu MDF para um armazenamento que possa lidar com E / S aleatórias e rápidas. SSD. Fusion-IO se você tiver o dinheiro. Infelizmente, este é um daqueles sintomas que não podem ser resolvidos com uma RAM mais barata ...

Editar:

Como Mark aponta, você tem dois discos lógicos apoiados por um disco físico. Talvez você tenha tentado seguir as práticas recomendadas e dividir o logon D: e os dados em C: mas infelizmente não adianta, C e D são o mesmo disco. Entre os pontos de verificação, você obtém uma taxa de transferência seqüencial, mas, assim que a verificação é iniciada, as cabeças do disco começam a se mover e a taxa de transferência do log é reduzida, reduzindo a taxa de transferência inteira do aplicativo. Certifique-se de separar o log do banco de dados para que não seja afetado pelos dados IO (disco separado).