Por que as consultas do SQL Server não usam mais de 7 MB / s de E / S de disco

Eu tenho um SSD que, usando o teste IOmeter, mostra desempenho acima de 200 MB / s. No entanto, quando executo qualquer consulta SQL da máquina local, o monitor de recursos do Windows nunca mostra E / S de disco acima de 7 MB / s. Isso vale mesmo para consultas que levam mais de 2 minutos para serem executadas. Qual poderia ser o gargalo em usar apenas 7 MB / s de SSD?

Estou correndo:

Windows Server 2012 Standard
SQL Server 2008 r2
Intel i7 3820
32GB de ram
sandisk SSD

sql-server sql-server-2008-r2 hardware

— Dean MacGregor
fonte

talvez os dados já estejam na RAM e não seja necessário acesso ao disco?

— gbn 21/01

@ DeanMacGregor - Como você está consumindo os resultados? Se no SSMS, e se você tentar a opção de descartar os resultados. Isso muda alguma coisa? Além disso, você pode tentar olhar sys.dm_os_waiting_tasksenquanto a consulta está sendo executada para ver se há outros tipos de espera que está encontrando.

— Martin Smith

Os 200 MB / s são para leituras de acesso aleatório (leituras aleatórias para blocos de 4 KB)? Eu acho que isso é o que um banco de dados normalmente faria. A consulta grava no disco (arquivo temporário, conjunto de resultados temporário ou tabela)?

@ DeanMacGregor - Então, para tirar isso da equação, você pode atribuir o resultado a variáveis escalares (consulta de exemplo). DECLARE @Name VARCHAR(10), @High int; SELECT @Name=name, @High = high FROM master..spt_values. Portanto, nenhum resultado é enviado de volta ao cliente, mas o plano e o IO ainda serão os mesmos.

— Martin Smith

Suponha que você esteja interpretando ASYNC_NETWORK_IO espera que o problema esteja relacionado à rede? (Normalmente) não é. É mais provável que o @MartinSmith tenha sugerido (duas vezes) que o SSMS ou o aplicativo que você está usando não consuma os resultados tão rapidamente quanto o SQL os está fornecendo. Siga uma das maneiras sugeridas de omitir o consumo das linhas e você terá uma imagem verdadeira (r) da taxa de transferência máxima de E / S.

— Mark Storey-Smith

Da cadeia de comentários, parece que você está interpretando ASYNC_NETWORK_IOesperas para significar que o problema está relacionado à rede. (Normalmente) não é.

Como o @MartinSmith sugeriu (duas vezes), a explicação mais provável para isso é o SSMS ou o aplicativo que você está usando, não consumindo os resultados tão rapidamente quanto o SQL Server os está fornecendo. Siga um dos métodos sugeridos para remover o consumo das linhas da sua medição e você terá uma imagem verdadeira (r) da taxa de transferência máxima de E / S:

Caso ainda não o tenha, obviamente será necessário DBCC DROPCLEANBUFFERSgarantir que os dados sejam realmente lidos no disco, e não no cache do buffer. Aplicam-se advertências usuais de "apenas em teste, não faça isso em um ambiente ativo", etc.

Aprimorando alguns de seus outros comentários:

Ao executar uma consulta que retorne 9 milhões de linhas, o uso da CPU permanecerá em torno de 13%, com 9% atribuível ao sqlserver ... não retornaria os resultados mais rapidamente do que 3 min se todos os dados estivessem na RAM?

O que exatamente estamos testando aqui, como e por quê? Se a sua consulta de 9 milhões de linhas não for uma SELECT * FROM dbo.SomeTable, existem 1001 fatores a serem reproduzidos, além da taxa de transferência bruta de IO.

Seu Intel I7-3820 é um processador de 4 núcleos. Se sua consulta de teste não gerar um plano paralelo, ficaria surpreso se você pudesse debulhar mais de 20% da utilização da CPU do sistema.

Os 3 minutos para retornar 9 milhões de linhas são muito suspeitos e sugerem que não estamos tendo uma visão completa do que está sendo testado. Meu palpite seria que este é um caso de um plano de consulta subótimo (não paralelo), cheio de operadores de loop aninhado que puxam milhões de linhas, ou seja, não apenas uma tabela SELECTpara verificar o consumo de IO.

Eu sugiro:

SELECT *para testar apenas IO através do SQL Server.
Nova pergunta com o plano de execução da sua consulta, se você quiser descobrir por que ela não satura o IO.

— Mark Storey-Smith
fonte

Na verdade, basta selecionar * no dbo.sometable. Desculpe não ter mencionado isso antes; o que eu quis dizer foi que eu poderia executar essa consulta em qualquer tabela. A gênese da minha pergunta foi que eu notei que a IO do meu disco era muito menor do que eu esperava, mesmo com uma simples consulta "me dê muitos dados". Minha principal preocupação era que, se a E / S de disco for tão baixa, o desempenho poderia ser melhorado se a causa raiz da E / S de disco baixa estivesse erradicada.

— precisa saber é o seguinte