Высокая скорость дискового ввода-вывода с сервера sql или высокая скорость дискового ввода-вывода замедляет работу сервера sql?

Я спорил с администратором базы данных и парой аппаратных парней о проблемах производительности на нашем сервере SQL. Обычно все в порядке, однако в последние несколько недель мы наблюдаем огромные задержки в работе сервера sql. Понятно, что SQL Server ожидает дискового ввода-вывода. Но мне постоянно говорят, что это так, потому что SQL Server запрашивает аномально высокий ввод-вывод. Что не так. Из того, что работает, я вижу, что нет ничего необычного, и все, что БД заботится, - это то, что вызывает блокировку и т. Д., Что бесполезно. Например, главное, что мы видим при резервном копировании, - это работа с базой данных ASPState, которую мы используем для управления состоянием сеанса ASP на веб-серверах. Эти операции обычно никогда не видны на активных результатах Sp_who2, потому что они происходят так быстро. База данных находится в простом режиме восстановления, и ведение журнала является минимальным. Однако во время этих скачков задержки мы можем видеть множество операций выбора и обновления базы данных, которые заблокированы или ожидают. Я уверен, что происходит то, что кто-то или какая-то работа выполняет что-то, что вызывает тяжелое использование диска в массивах raid, используемых для этого журнала баз данных и файлов данных. Проблема в том, чтобы доказать это, поскольку никто не хочет признать, что они делают что-то, что убивает наш сайт.

Мой вопрос заключается в том, какие счетчики производительности или что я могу зарегистрировать, что поможет показать, что SQL-сервер ожидает ввода-вывода, но не потому, что он запрашивает больше, чем обычно, вместо этого, поскольку диск занят, чтобы отвечать на запросы от сервера SQL так быстро, как обычно?

Посмотрите на следующие счетчики perfmon:

• SQL Server, объект диспетчера буфера :
  Page lookups/sec
Page reads/sec
Readahead pages/sec
• SQL Server, объект методов доступа
  Full Scans/sec
Range Scans/sec
Skipped Ghosted Records/sec
• SQL Server, объект статистики ожидания
  Page IO latch waits

SQL Server, выполняющий большое количество запросов ввода-вывода, будет подтвержден большим числом сканирований, увеличением числа просмотров страниц и чтений страниц, а также большим числом ожидающих защелок ввода-вывода страниц. Стоит попробовать взглянуть на sys.dm_exec_query_statsзаписи с высокими показателями физического чтения. Они могли быстро определить виновника.

В общем, подход к проблеме как к проблеме устранения проблем производительности, следуя методологии, такой как Ожидания и Очереди, является правильным подходом. Кажется, ваш администратор баз данных поступает правильно, поэтому вам следует его послушать.

Для того, чтобы начать использовать Гленн Берри Диагностические запросы и Адама Machanic в SP_Whoisactive , чтобы узнать, Что происходит на самом деле.

Сначала посмотрите, какие файлы базы данных имеют наибольшее узкое место ввода-вывода, выполнив этот запрос (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 );

Затем выполните этот запрос, чтобы увидеть первые десять событий, которые ожидает ваш сервер (запрос Джонатана Кехайяса ). Вы также найдете аналогичный запрос из диагностических запросов Гленна Берри.

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

Если у вас есть эта информация под рукой, вам будет намного легче устранить проблему.

Кстати, вы можете найти много сообщений о том, как использовать sp_whoisactive для устранения неполадок здесь.

«Проблема доказывает это», правильно сказал. Взгляните на SQL Server: минимизируйте дисковый ввод-вывод

Речь идет о следовании DMV

sys.dm_io_virtual_file_stats
sys.dm_io_pending_io_requests

Ссылки:

1. Как проверить задержки подсистемы ввода-вывода из SQL Server
2. Производительность SQL Server Гленна Берри - sys.dm_io_pending_io_requests