High Disk I / O z serwera sql czy może High Disk I / O spowalnia serwer sql?

Kłóciłem się z DBA i kilkoma facetami od sprzętu o problemy z wydajnością na naszym serwerze SQL. Normalnie wszystko jest w porządku, jednak w ciągu ostatnich kilku tygodni mieliśmy ogromne opóźnienia w serwerze SQL. Oczywiste jest, że SQL Server czeka na dysku we / wy. Ale ciągle słyszę, że to dlatego, że SQL Server prosi o nienormalnie wysokie operacje we / wy. Tak nie jest. Z tego, co się dzieje, widzę, że nie ma nic nienormalnego, a wszystkim, na co DBA patrzy, jest to, co powoduje blokowanie i tak dalej, co jest bezużyteczne. Na przykład najważniejszą rzeczą, którą widzimy podczas tworzenia kopii zapasowej, jest działanie w bazie danych ASPState, której używamy do zarządzania stanem sesji ASP na serwerach internetowych. Operacje te zwykle nie są widoczne dla aktywnych wyników Sp_who2, ponieważ występują tak szybko. Baza danych znajduje się w prostym trybie odzyskiwania, a rejestrowanie jest nielegalne. Jednak podczas tych skoków opóźnienia widzimy wiele operacji wyboru i aktualizacji bazy danych, które są blokowane lub czekają. Jestem pewien, że dzieje się tak, że ktoś lub jakieś zadanie wykonuje coś, co powoduje ciężkie użycie dysku w macierzach RAID używanych dla dzienników baz danych i plików danych. Problem polega na tym, że nikt nie chce przyznać, że robi coś, co zabija naszą stronę internetową.

Moje pytanie dotyczy tego, jakie liczniki wydajności lub cokolwiek mogę zarejestrować, co pomoże pokazać, że serwer SQL czeka na operacje we / wy, ale nie dlatego, że prosi o więcej niż normalnie, ponieważ dysk jest zajęty, aby odpowiedzieć na żądania serwera SQL tak szybko jak zwykle?

Spójrz na następujące liczniki perfmon:

• SQL Server, obiekt Menedżera buforów :
  Page lookups/sec
Page reads/sec
Readahead pages/sec
• SQL Server, obiekt metod dostępu
  Full Scans/sec
Range Scans/sec
Skipped Ghosted Records/sec
• SQL Server, obiekt statystyk czekania
  Page IO latch waits

Program SQL Server sterujący dużą liczbą żądań We / Wy zostałby potwierdzony skanowaniem dużej liczby, wzrostem liczby wyszukiwań stron i odczytów stron oraz oczekiwaniem na zatrzaśnięcie We / Wy strony. Warto spojrzeć na sys.dm_exec_query_statswpisy o wysokiej liczbie odczytów fizycznych. Mogą szybko wskazać winowajcę.

Zasadniczo podejście do problemu jako do rozwiązania problemu z wydajnością, właściwe jest zastosowanie metodologii takiej jak oczekiwania i kolejki . Ty, DBA, wydajesz się postępować właściwie, więc powinieneś go słuchać.

Aby zacząć korzystać z zapytań diagnostycznych Glenna Berry'ego i SP_Whoisactive Adama Machanica, aby dowiedzieć się, co się naprawdę dzieje.

Najpierw sprawdź, które pliki bazy danych mają najwięcej wąskich gardeł we / wy, uruchamiając to zapytanie (zapytanie Glenna Berry'ego)

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 );

Następnie uruchom to zapytanie, aby zobaczyć dziesięć najważniejszych zdarzeń, na które czeka Twój serwer (zapytanie Jonathana Kehayiasa ). Podobne zapytanie znajdziesz również w zapytaniach diagnostycznych 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

Gdy będziesz mieć te informacje pod ręką, znacznie łatwiej będzie rozwiązać problem.

BTW możesz znaleźć wiele postów na temat używania sp_whoisactive do rozwiązywania problemów tutaj.

„Problemem jest udowodnienie tego”, słusznie powiedział. Spójrz na SQL Server: Minimalizuj dysk I / O

Mówi o śledzeniu DMV

sys.dm_io_virtual_file_stats
sys.dm_io_pending_io_requests

Bibliografia:

1. Jak sprawdzić opóźnienia podsystemu IO z poziomu SQL Server
2. Wydajność SQL Server Glenna Berry'ego - sys.dm_io_pending_io_requests