Високий дисковий введення / вивід з sql-сервера або високий диск вводу / виводу уповільнює sql-сервер?

Я сперечався з DBA та парою апаратних хлопців з приводу проблем продуктивності на нашому SQL-сервері. Зазвичай все нормально, проте за останні кілька тижнів у нас спостерігаються величезні відставання у сервері sql. Зрозуміло, що SQL Server очікує на введення / вивід диска. Але мені постійно кажуть, що саме SQL Server просить аномально високого вводу / виводу. Що не так. Я бачу з того, що працює, що нічого нормального немає, і все, що DBA намагається подивитися, це те, що викликає блокування і так далі, що марно. Наприклад, головне, що ми бачимо резервне копіювання - це робота з базою даних ASPState, яку ми використовуємо для управління станом сеансу ASP на веб-серверах. Ці операції зазвичай не спостерігаються на активних результатах Sp_who2, оскільки вони відбуваються так швидко. База даних перебуває в простому режимі відновлення, а журнал - злочинний. Однак під час цих стрибків затримки ми можемо бачити багато операцій з вибору та оновлення в БД, що блокуються або чекають. Я впевнений, що відбувається в тому, що хтось або якась робота виконує щось, що спричиняє використання важких дисків на рейдових масивах, використовуваних для цього журналу баз даних та файлів даних. Проблема доводить це, оскільки ніхто не хоче визнати, що вони роблять щось, що вбиває наш веб-сайт.

Моє запитання - які лічильники продуктивності чи що я можу ввійти, що допоможе показати, що SQL-сервер чекає на введення-виведення, але не тому, що його просять більше, ніж зазвичай, замість цього, оскільки диск зайнятий, щоб відповісти на запити сервера sql так швидко, як це було б нормально?

Подивіться на наступні лічильники парфмонів:

• SQL Server, Buffer Manager Об'єкт :
  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, що підтримує велику кількість запитів вводу-виводу, підтверджується великим скануванням чисел, збільшенням кількості оглядів сторінок та читанням сторінок та очікуванням високої засувки IO сторінки. Варто спробувати ознайомитись із sys.dm_exec_query_statsзаписами з великими фізичними значеннями читання. Вони могли швидко визначити винуватця.

Як правило, підхід до проблеми як проблема усунення продуктивності, правильний підхід дотримується такої методики, як "Чекання та черги ". Ви, схоже, DBA робите правильно, тому вам слід його слухати.

Для початку використовуйте діагностичні запити Глена Беррі та 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 );

Потім запустіть цей запит, щоб побачити десятку найкращих подій, на які очікує ваш сервер (запит Джонатана Кехаяса ). Ви також знайдете подібний запит від діагностичних запитів 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

Якщо у вас є ця інформація під рукою, усунути проблему було б набагато простіше.

BTW Ви можете знайти багато публікацій про те, як використовувати sp_whoisactive для усунення несправностей тут.

"Проблема доводить це", справедливо сказано. Погляньте на SQL Server: мінімізація вводу / виводу диска

Мова йде про наступний ДМВ

sys.dm_io_virtual_file_stats
sys.dm_io_pending_io_requests

Список літератури:

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