Perché le query di SQL Server non utilizzano più di 7 MB / sec di I / O su disco

Ho un SSD che, usando il test IOmeter, mostra prestazioni superiori a 200 MB / s. Tuttavia, quando eseguo qualsiasi query SQL dal computer locale, il monitoraggio delle risorse di Windows non mostra mai l'IO del disco superiore a 7 MB / sec. Ciò vale anche per l'esecuzione di query che richiedono più di 2 minuti. Quale potrebbe essere il collo di bottiglia che utilizza solo 7 MB / sec da SSD?

Sto correndo:

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

sql-server sql-server-2008-r2 hardware

— Dean MacGregor
fonte

forse i dati sono già nella RAM e non è necessario l'accesso al disco?

— gbn

@DeanMacGregor - Come stai consumando i risultati? Se in SSMS cosa succede se si prova l'opzione per eliminare i risultati. Questo cambia qualcosa? Inoltre potresti provare a guardare sys.dm_os_waiting_tasksmentre la query è in esecuzione per vedere se ci sono altri tipi di attesa che sta incontrando.

— Martin Smith,

I 200 MB / s sono per letture ad accesso casuale (letture casuali per blocchi da 4 KB)? Immagino che questo sia ciò che farebbe normalmente un database. La query scrive sul disco (file temporaneo, set di risultati temporaneo o tabella)?

@DeanMacGregor - Quindi, per toglierlo dall'equazione, puoi assegnare il risultato a variabili scalari (esempio di query). DECLARE @Name VARCHAR(10), @High int; SELECT @Name=name, @High = high FROM master..spt_values. Quindi nessun risultato viene restituito al client, ma il piano e IO saranno sempre gli stessi.

— Martin Smith,

Supponiamo che tu stia interpretando ASYNC_NETWORK_IO in attesa di significare che il problema è legato alla rete? Non lo è (in genere). È molto probabile che @MartinSmith abbia suggerito (due volte) che SSMS o l'applicazione che stai utilizzando non stanno consumando i risultati con la stessa rapidità con cui SQL li sta offrendo. Segui uno dei modi suggeriti per omettere il consumo delle righe e otterrai un'immagine vera (r) del throughput massimo di IO.

— Mark Storey-Smith,

Dalla catena di commenti, sembra che tu stia interpretando le ASYNC_NETWORK_IOattese per indicare che il problema è legato alla rete. Non lo è (in genere).

Poiché @MartinSmith ha suggerito (due volte) la spiegazione più probabile per questo è SSMS o l'applicazione che stai utilizzando non consuma i risultati così velocemente come SQL Server li sta servendo. Segui uno dei metodi suggeriti per rimuovere il consumo delle righe dalla tua misurazione e otterrai un'immagine vera (r) del throughput massimo di IO:

Nel caso non lo avessi già fatto, dovrai ovviamente DBCC DROPCLEANBUFFERSassicurarti che i dati vengano effettivamente letti dal disco piuttosto che dalla cache del buffer. Si applicano le solite avvertenze di "solo su test, non farlo in un ambiente live attivo" ecc.

Affina un paio di altri tuoi commenti:

Mentre l'esecuzione di una query che restituisce 9 milioni di righe, l'utilizzo della CPU rimarrà circa il 13% con il 9% attribuibile a sqlserver ... non restituirebbe i risultati più rapidamente di 3 minuti se tutti i dati fossero nella RAM?

Cosa stiamo testando esattamente qui, come e perché? Se la tua query da 9 milioni di righe è diversa da una, SELECT * FROM dbo.SomeTableallora ci sono 1001 fattori che entrano in gioco, oltre al semplice throughput IO grezzo.

Il tuo Intel I7-3820 è un processore a 4 core. Se la tua query di prova non genera un piano parallelo, sarei sorpreso se tu potessi scaricare oltre il 20% di utilizzo della CPU dal sistema.

I 3 minuti per restituire 9 milioni di righe sono molto sospetti e suggeriscono che non avremo un quadro completo di ciò che i tuoi test. La mia ipotesi sarebbe che questo sia un caso di piano di query non ottimale (non parallelo), pieno di operatori a ciclo nidificato che eseguono il pull di milioni di righe, vale a dire non solo una singola tabella SELECTper verificare il consumo di I / O.

Suggerisco:

SELECT *per testare solo IO tramite SQL Server.
Nuova domanda con il piano di esecuzione della query se si desidera approfondire il motivo per cui non saturare l'IO.

— Mark Storey-Smith
fonte

In realtà è sufficiente selezionare * da dbo.sometable. Mi dispiace non averlo menzionato prima; intendevo dire che avrei potuto eseguire quella query da qualsiasi tabella. La genesi della mia domanda è che ho notato che l'IO del mio disco era molto meno di quanto mi aspettassi anche dalla semplice query "dammi molti dati". La mia preoccupazione principale era che se l'IO del disco fosse così basso le prestazioni potevano essere migliorate se fosse stata sradicata la causa principale dell'IO del disco basso.

— Decano MacGregor il