it-swarm-eu.dev

Vysoký disk I / O ze serveru SQL nebo zpomaluje server sql s vysokým diskem I / O?

Hádám se s DBA a několika hardwarovými kluky o problémech s výkonem na našem serveru SQL. Normálně je vše v pořádku, během posledních několika týdnů jsme však měli na serveru SQL obrovskou prodlevu. Je jasné, že SQL Server čeká na disku I/O. Ale stále mi říkají, že je to proto, protože SQL Server požaduje neobvykle vysoké I/O. Což tak není. Z toho, co běží, vidím, že není nic neobvyklého, a všechny, na které se DBA zajímá, je to, co způsobuje blokování atd., Což je zbytečné. Například hlavní věc, kterou vidíme, je zálohování, je operace v databázi ASPState, kterou používáme ke správě ASP stav relace na webových serverech. Tyto operace se za aktivních výsledků Sp_who2 obvykle nikdy nevidí). protože se vyskytují tak rychle. Databáze je v režimu jednoduchého zotavení a protokolování je miminální. Během těchto zpožděných hrotů však vidíme mnoho operací výběru a aktualizace na blokované nebo čekající databázi. Jsem si jist, že se děje to, že někdo nebo nějaká úloha spouští něco, co způsobuje využití diskových oddílů na raidových polích používaných pro protokolové a datové soubory databází. Problém to dokazuje, protože nikdo nechce připustit, že dělají něco, co zabíjí naše webové stránky.

Moje otázka je, jaké čítače výkonu nebo cokoli, co mohu přihlásit, což pomůže ukázat, že SQL server čeká na I/O, ale ne proto, že by vyžadoval více než normálně, místo toho, protože disk je zaneprázdněn odpovědí na požadavky ze serveru SQL tak rychle, jak by to normálně bylo?

18
Edgey

Podívejte se na následující čítače perfmonů:

SQL Server, který řídil vysoký počet IO žádostí by byl potvrzen velkým počtem skenování, zvýšeným vyhledáváním stránek a čtení stránek a vysokou stránkou IO čeká na západku). Stojí za to vyzkoušet sys.dm_exec_query_stats pro záznamy s vysokým počtem fyzických čtení. Mohli by rychle identifikovat vinníka.

Obecně se k problému přistupuje jako k řešení problémů s výkonem, po metodice jako Waits and Queues je správný přístup. Zdá se, že vy DBA děláte správnou věc, takže byste ho měli poslouchat.

19
Remus Rusanu

Chcete-li zjistit, co se skutečně děje, použijte Diagnostické dotazy = a Glen Machanic SP_Whoisactive .

Nejprve zjistěte, které databázové soubory mají nejvíce IO úzký profil spuštěním tohoto dotazu (Query by 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 );

Poté spusťte tento dotaz, abyste viděli prvních deset událostí, na které server čeká (dotaz Jonathan Kehayias ). Podobný dotaz najdete také v diagnostických dotazech 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

Jakmile budete mít tyto informace po ruce, bude mnohem snazší problém vyřešit.

BTW najdete mnoho příspěvků o tom, jak používat sp_whoisactive pro řešení problémů zde.

12
DaniSQL

"Problém je to dokazovat," řekl správně. Podívejte se na SQL Server: Minimize Disk I/O

Jedná se o sledování DMV

sys.dm_io_virtual_file_stats
sys.dm_io_pending_io_requests

Odkazy:

  1. Jak zkoumat IO latence subsystému zv rámci SQL Server
  2. Výkon serveru SQL Glenn Berry - sys.dm_io_pending_io_requests
1
LCJ