I / O disco alto dal server sql o I / O disco alto rallenta il server sql?

18

Ho discusso con un DBA e un paio di ragazzi hardware su problemi di prestazioni sul nostro server SQL. Normalmente tutto va bene, tuttavia nelle ultime settimane abbiamo avuto enormi picchi di ritardo nel server sql. È chiaro che SQL Server è in attesa sull'I / O del disco. Ma continuo a sentirmi dire che SQL Server richiede I / O anormalmente elevati. Non è così. Vedo da ciò che sta funzionando che non c'è nulla di normale, e tutto ciò che la DBA si preoccupa di guardare è ciò che sta causando il blocco e così via, il che è inutile. Ad esempio, la cosa principale che vediamo fare il backup è l'operazione sul database ASPState, che stiamo usando per gestire lo stato della sessione ASP sui server web. Queste operazioni normalmente non vengono mai visualizzate sui risultati attivi di Sp_who2 perché avvengono così rapidamente. Il database è in modalità di ripristino semplice e la registrazione è di importanza fondamentale. Tuttavia durante questi picchi di ritardo possiamo vedere molte operazioni di selezione e aggiornamento sul database bloccate o in attesa. Sono sicuro che ciò che sta succedendo è che qualcuno o qualche lavoro sta eseguendo qualcosa che sta causando l'utilizzo del disco heavey sugli array raid utilizzati per quel registro di database e file di dati. Il problema lo sta dimostrando, dal momento che nessuno vuole ammettere che stanno facendo qualcosa che sta uccidendo il nostro sito web.

La mia domanda è: quali contatori delle prestazioni o qualunque cosa sia possibile registrare che possa aiutare a dimostrare che il server SQL è in attesa sull'I / O, ma non perché richiede più del normale, perché il disco è occupato a rispondere alle richieste del server SQL più rapidamente di quanto farebbe normalmente?

sql-server  perfmon 
— Edgey
fonte
3
Quale stato di attesa stai effettivamente visualizzando, Network I / O? cioè, stai usando una SAN?
— Eric Higgins,
Verificare se sono presenti query che stanno dominando l'utilizzo delle risorse sul server DB. Se ci sono, prova a sintonizzarli. Se non si hanno query che si comportano male, le alte attese di PAGEIOLATCH indicano che il sistema è associato a I / O. Inoltre, come dice @EricHiggins, le SAN sono spesso lente e causano problemi di prestazioni con i database.
— Preoccupato di
È un array NETAPP collegato al server sql con HBA in fibra Qlogic.
— Edgey,
So che questa è una domanda relativamente vecchia e che non risolverà direttamente il tuo problema ... ma siamo passati a aspnet_state.exe per lo stato della sessione e abbiamo visto un grande carico fuori dal nostro SQL Server. Non è ben documentato ma abbastanza facile da configurare.
— MattGWagner,
Quindi cosa hai fatto tu / il DBA e qual è stato il problema?
— Mukus,

Risposte:

19

Dai un'occhiata ai seguenti contatori di perfoni:

SQL Server che guida un numero elevato di richieste IO verrebbe corroborato da un numero elevato di scansioni, aumento delle ricerche di pagine e letture di pagine e attese di aggancio IO di pagine elevate. Vale la pena di dare un'occhiata a sys.dm_exec_query_statsvoci con conteggi di letture fisiche elevate. Potrebbero individuare rapidamente il colpevole.

In generale, affrontare il problema come un problema di risoluzione delle prestazioni, seguire un metodo come Waits and Queues è l'approccio giusto. Il tuo DBA sembra fare la cosa giusta, quindi dovresti ascoltarlo.

— Remus Rusanu
fonte
Non ho problemi con il DBA, è uno dei migliori DBA con cui ho lavorato. E mi ha dato un elenco di stored procedure con blocco elevato. Ma come ho già detto, uno dei proc che sta causando molti blocchi è "TempUpdateStateItemLong" che è un proc usato dall'archivio di stato della sessione SQL hte. È un proc di MS e aggiorna solo una singola tabella da sessionID che è la chiave primaria indicizzata sulla tabella. Anche al massimo questa tabella ha record 2000-3000, quindi gli aggiornamenti non dovrebbero richiedere tempo.
— Edgey,
Questo è un buon punto di partenza. Stiamo ancora eseguendo SQL Server 2000, siamo in fase di aggiornamento ma questo non accadrà per qualche altro mese, quindi non ho il PAge IO Latch in attesa di contatore. Grazie ancora.
— Edgey,
Si noti che il blocco di per sé non implica un IO elevato. Potrebbe essere una contesa di blocco e ciò influirebbe sulla tabella indipendentemente dalle dimensioni, specialmente se l'ottimizzatore sceglie un piano basato sulla scansione della tabella.
— Remus Rusanu,
E controlla anche il processo per IO Data Bytes/sece vedi se qualche altro processo sta distruggendo il disco.
— Remus Rusanu,
12

Per iniziare, utilizza le query diagnostiche di Glenn Berry e SP_Whoisactive di Adam Machanic per scoprire cosa sta realmente accadendo.

Per prima cosa vedi quali file di database hanno il maggior collo di bottiglia di IO eseguendo questa query (Query di Glenn Berry)

SELECT  DB_NAME(fs.database_id) AS [Database Name] ,
        mf.physical_name ,
        io_stall_read_ms ,
        num_of_reads ,
        CAST(io_stall_read_ms / ( 1.0 + num_of_reads ) AS NUMERIC(10, 1)) AS [avg_read_stall_ms] ,
        io_stall_write_ms ,
        num_of_writes ,
        CAST(io_stall_write_ms / ( 1.0 + num_of_writes ) AS NUMERIC(10, 1)) AS [avg_write_stall_ms] ,
        io_stall_read_ms + io_stall_write_ms AS [io_stalls] ,
        num_of_reads + num_of_writes AS [total_io] ,
        CAST(( io_stall_read_ms + io_stall_write_ms ) / ( 1.0 + num_of_reads
                                                          + num_of_writes ) AS NUMERIC(10,
                                                              1)) AS [avg_io_stall_ms]
FROM    sys.dm_io_virtual_file_stats(NULL, NULL) AS fs
        INNER JOIN sys.master_files AS mf WITH ( NOLOCK ) ON fs.database_id = mf.database_id
                                                             AND fs.[file_id] = mf.[file_id]
ORDER BY avg_io_stall_ms DESC
OPTION  ( RECOMPILE );

Quindi esegui questa query per vedere i primi dieci eventi su cui il tuo server è in attesa (query di Jonathan Kehayias ). Troverai anche query simili dalle query diagnostiche di Glenn Berry.

SELECT TOP 10
        wait_type ,
        max_wait_time_ms wait_time_ms ,
        signal_wait_time_ms ,
        wait_time_ms - signal_wait_time_ms AS resource_wait_time_ms ,
        100.0 * wait_time_ms / SUM(wait_time_ms) OVER ( ) AS percent_total_waits ,
        100.0 * signal_wait_time_ms / SUM(signal_wait_time_ms) OVER ( ) AS percent_total_signal_waits ,
        100.0 * ( wait_time_ms - signal_wait_time_ms )
        / SUM(wait_time_ms) OVER ( ) AS percent_total_resource_waits
FROM    sys.dm_os_wait_stats
WHERE   wait_time_ms > 0 -- remove zero wait_time
        AND wait_type NOT IN -- filter out additional irrelevant waits
( 'SLEEP_TASK', 'BROKER_TASK_STOP', 'BROKER_TO_FLUSH', 'SQLTRACE_BUFFER_FLUSH',
  'CLR_AUTO_EVENT', 'CLR_MANUAL_EVENT', 'LAZYWRITER_SLEEP', 'SLEEP_SYSTEMTASK',
  'SLEEP_BPOOL_FLUSH', 'BROKER_EVENTHANDLER', 'XE_DISPATCHER_WAIT',
  'FT_IFTSHC_MUTEX', 'CHECKPOINT_QUEUE', 'FT_IFTS_SCHEDULER_IDLE_WAIT',
  'BROKER_TRANSMITTER', 'FT_IFTSHC_MUTEX', 'KSOURCE_WAKEUP',
  'LAZYWRITER_SLEEP', 'LOGMGR_QUEUE', 'ONDEMAND_TASK_QUEUE',
  'REQUEST_FOR_DEADLOCK_SEARCH', 'XE_TIMER_EVENT', 'BAD_PAGE_PROCESS',
  'DBMIRROR_EVENTS_QUEUE', 'BROKER_RECEIVE_WAITFOR',
  'PREEMPTIVE_OS_GETPROCADDRESS', 'PREEMPTIVE_OS_AUTHENTICATIONOPS', 'WAITFOR',
  'DISPATCHER_QUEUE_SEMAPHORE', 'XE_DISPATCHER_JOIN', 'RESOURCE_QUEUE' )
ORDER BY wait_time_ms DESC

Una volta che hai a portata di mano queste informazioni, sarebbe molto più facile risolvere il problema.

A proposito, puoi trovare molti post su come utilizzare sp_whoisactive per la risoluzione dei problemi qui.

— DaniSQL
fonte
1
Ho appena usato la sceneggiatura finale in questo elenco - il suo culo.
— the_good_pony
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.