por que o io_stall_writes_ms é muito mais alto para o tempdb?

Temos os arquivos de dados do usuário e do sistema na mesma unidade de disco. O (io_stall_write_ms / (1.0 + num_of_writes)) está abaixo de 2 para os arquivos do usuário, mas os arquivos tempdb costumam ter mais de 400. Vejo isso em alguns servidores e estou curioso para saber se há uma razão para levar mais tempo para gravar no tempdb do que um arquivo de dados regular do banco de dados.

SELECT DISTINCT UPPER(LEFT(mf.physical_name, 1)) AS Directory,
( io_stall_write_ms / ( 1.0 + num_of_writes ) ) as result, 
io_stall_write_ms, num_of_writes, 
fs.database_id, 
fs.[file_id]
FROM sys.dm_io_virtual_file_stats(NULL, NULL) AS fs
INNER JOIN sys.master_files AS mf ON fs.database_id = mf.database_id
AND fs.[file_id] = mf.[file_id]

Obrigado,

Resposta curta: Ver paradas de E / S mais altas pode ou não ser um problema por si só. Você precisa procurar mais informações para descobrir se há algum problema. Parece um pouco alto, sim, mas você está sofrendo? Nesse caso, provavelmente é porque seu sistema de E / S não está lidando com a carga corretamente (porque não pode, porque você tem tudo em uma unidade ou por algum outro motivo) ou está fazendo muito no TempDB (alterando o primeiro problema - o desempenho do IO - é provavelmente uma correção mais fácil e eficiente, mas primeiro determine se você tem um problema)

A discussão / resposta mais longa:

Há duas perguntas em jogo aqui -

1.) O que faço quando vejo altas paradas de IO?

Primeiro, "alto" está nos olhos de quem vê. Se você perguntasse a 10 DBAs o que "alto demais" é para barracas de IO, provavelmente você obteria 2-3 respostas diferentes com números, 5-6 respostas "Depende" e um olhar vazio. Minha suposição é de que uma média de 400ms é potencialmente muito alta aqui, especialmente quando os outros DBs são 2ms ou menos durante o tempo médio de estol.

Independentemente de qual banco de dados está vendo as paradas altas, você deve abordá-lo da mesma maneira. Uma paralisação de E / S é o que parece ... Uma solicitação de E / S está demorando mais que o esperado. Isso acontece. Elas acontecem o tempo todo em um sistema com recursos compartilhados e recursos finitos (na verdade todos os nossos sistemas). Eles se tornam um problema quando as barracas se tornam problemas de desempenho ou levam a eles. Portanto, confio que você esteja olhando aqui como parte proativa do monitoramento ou porque está enfrentando problemas de desempenho que estão solucionando. Também não queremos nos perder apenas em barracas de IO. Estamos olhando para uma peça do quebra-cabeça e não para o quadro geral. Pode ser problemático examinar apenas as estatísticas de espera ou de arquivo desde que o SQL foi reiniciado pela última vez, porque você está olhando o tempo todo e alguma janela de manutenção ou janela de carga pesada pode distorcer os contadores. Portanto, verifique a imagem completa.

Mas quando suspeito que tenho um problema de desempenho do disco ou vejo algo em uma consulta como essa, normalmente sigo um processo parecido com:

1. Veja as estatísticas de espera no servidor. @swasheck compartilhou um ótimo link como comentário em uma resposta abaixo. Isso leva você à postagem de Paul Randal, que analisa e analisa as estatísticas de espera no SQL Server. Vá ali. Que tipo de espera você está vendo? Você vê aguarda relacionadas com IO desempenho ( PAGEIOLATCH_*, IO_COMPLETION, WRITELOG, etc.?). Se você fizer isso, é outra indicação de que você tem alguns problemas de desempenho relacionados às E / S, assim como as paradas de E / S. Mas dá a você outra forma de acordo aqui.
2. Veja o desempenho de IO. Em particular, observe o perfmon nos contadores Physical Disk:Avg Disk Sec/Reade Avg Sec Disk Sec/Write. Eles medem sua latência. Assista a esses contadores por um período salvo em um arquivo de log de desempenho. O que você viu para as médias? Se você estiver vendo números com mais de 0,020 segundos (20ms), isso pode ser um problema. Se você vir números acima de 40-50ms méd ou mais, é uma indicação mais firme de um problema. Veja também seus picos? Quão alto eles vão e quanto tempo eles duram? Se você observar picos nas centenas de ms e eles durarem dezenas ou dezenas de segundos ou mais e / ou ocorrerem com frequência, é mais provável que você tenha um problema com o desempenho do seu pedido de veiculação para sua carga de trabalho.
3. Veja sua configuração de E / S. O que é isso? Discos locais? SAN? Matriz de armazenamento? Que tipo de PIO e PIO você deveria ver disso? É suficiente para o que você está tentando fazer? Você pode ter subdimensionado seu IO para sua carga de trabalho. Não olhe apenas para seus eixos físicos, configurações de RAID, etc. Veja os caminhos para os discos. Você está empurrando tudo através de um único link de 1 GB que está compartilhando com muitos outros tráfegos? Você pode analisar as métricas de desempenho do disco da perspectiva do armazenamento.

( Nota: para esta análise de estatísticas de espera e análise de desempenho - observe vários períodos e tipos de uso. Você tem estatísticas de uso diferentes à noite do que durante o dia? Janelas de processamento em lote? Janelas de manutenção nas quais você reconstrói muitos índices? Observe essas ferramentas durante cada um desses períodos e entenda o que você está vendo para cada)

Outra consideração de desempenho de IO aqui -

• Você disse que os bancos de dados do sistema e de usuário são compartilhados. Essa produção é? Nesse caso, esse nem sempre é o melhor cenário. Você também está compartilhando arquivos de log e arquivos de dados nas mesmas unidades? Esse também não é o melhor cenário. O que mais compartilha esse armazenamento? Em um mundo em que você está preocupado com eixos, grupos e discos de invasão e precisa tomar decisões sobre quem obtém os discos com melhor desempenho, eu costumo fazê-lo (como regra geral, o que não é bom ter no mundo do DB mas este tende a ser verdadeiro) segue o meu mais rápido e mais dedicado ao TempDB (mais sobre isso abaixo), depois os arquivos de log e os arquivos de dados. Em um mundo em que você tem uma grande pilha de discos em um dispositivo como NetApp, Dell Equal Logic ou EMC VNX, etc., você não

2.) Quais são algumas das razões pelas quais o TempDB pode ser maior?

Portanto, o TempDB é um banco de dados e pode ter interrupções de IO como qualquer outro banco de dados, como acabei de discutir. Mas quais são algumas das razões pelas quais o TempDB pode ter leituras mais altas? (não exaustivo, congratulo-me com adições ou pensamentos em edições, outras respostas ou comentários) -

1. Por causa do seu código - você está usando muito o TempDB no seu código intencionalmente? Muitas tabelas temporárias e variáveis ​​de tabela criadas e destruídas? Fazendo muitas coisas no TempDB assim? Isso não é ruim ou bom necessariamente, mas você pode olhar para isso e entender seu padrão de uso intencional do TempDB.
2. TempDB é um cavalo de batalha compartilhado - TempDB é um banco de dados usado como um espaço temporário para objetos temporários definidos pelo usuário e várias tabelas de trabalho e operações usadas por toda a sua instância SQL. Quantos bancos de dados de usuários existem? Que tipo de carga de trabalho você vê em geral? O TempDB é um recurso para compartilhar tudo.
3. Consultas ineficientes e memória insuficiente - Talvez existam consultas que não estejam usando índices suficientemente rígidos ou que estejam executando grandes operações de verificação e classificação. Operações de hash grandes e a memória no servidor não é suficiente para elas. Essas operações serão "derramadas" para o TempDB como tabelas de trabalho nos bastidores. Às vezes, isso pode ser evitado observando seus planos de consulta e indexação ou ajuste de consulta. Às vezes acontece (acho que mais nas cargas de trabalho do armazém). Se você tiver memória suficiente, isso pode ajudar, mas essas consultas ainda podem se espalhar às vezes. Veja isso também.
4. Você está usando o nível Ler isolamento de snapshot confirmado com um número razoável de atualizações em seu sistema? Isso também pode resultar no aumento da atividade do TempDB.

O ponto é - o TempDB é usado de várias maneiras, e não me surpreende vê-lo como um dos seus bancos de dados mais movimentados, se não o mais movimentado. Também não me surpreende quando o vejo com o maior número e a maior média de paradas de todos os bancos de dados no site de um cliente. Às vezes, é a natureza de sua carga de trabalho. Observar algumas das coisas que mencionei aqui certamente pode ajudá-lo a determinar se esses números indicam um problema e, em caso afirmativo, como aprofundar sua solução.

O TempDB é compartilhado entre todos os bancos de dados da instância. Portanto, às vezes pode haver contenção no TempDB para determinadas páginas: SGAM , GAM e PFS . Em poucas palavras, essas páginas acompanham o que tem sido usado no TempDB até agora e onde há espaço disponível para novo uso.

Normalmente, isso é resolvido adicionando vários arquivos de dados ao TempDB. Existem algumas filosofias diferentes quanto ao número correto, mas todos concordam que você deve ter mais de um.

Aqui estão algumas consultas para executar ...

Este mostrará quantos arquivos o TempDB possui e onde estão localizados.

-- tempdb layout
use tempdb
go
exec sp_helpfile
go

Este mostrará a você quantas CPUs e núcleos você possui.

-- cores and hyperthreading
select cpu_count, hyperthread_ratio 
from sys.dm_os_sys_info
go

Este mostrará quantos nós e núcleos NUMA por nó NUMA você possui.

-- numa nodes and schedulers
select node_id, online_scheduler_count
from sys.dm_os_nodes
order by node_id
go

Este mostrará quais páginas estão com esperas no TempDB.

-- see if anything is waiting on tempdb
select * 
from sys.dm_os_waiting_tasks
where resource_description like '2:%'
go

Aqui está um artigo que aborda um pouco mais a fundo a questão da contenção de páginas.

OK, agora a parte da filosofia ... :-)

Para mim, se eu estiver em um sistema SMP , quero apenas tantos arquivos quanto a metade do total de núcleos .

Se eu estiver em um sistema NUMA , desejarei apenas o número de arquivos quantos núcleos por nó NUMA .

No entanto, raramente vejo melhorias por ter mais de quatro arquivos para o TempDB. Por isso, geralmente começo com quatro e monitoro a contenção, conforme explicado no artigo ao qual vinculei.

Se eu continuar tendo problemas, adicionarei mais dois. Verifique novamente, adicione mais e repita até a disputa desaparecer.