Назад | Перейти на главную страницу

Большое дисковое время на SQL Server

У нас есть специальный выпуск SQL Server 2008 R2 Enterprise Edition.

Настройка такова:

Сегодня мы переместили наши файлы журналов на новые диски (с F: на E :). С общего тома (F: (SAN)) на выделенные локальные диски (E :).

Затем произошло то, что "время на диске", "среднее время передачи" и "средняя длина очереди записи на диск" увеличились на томе, где у нас есть файлы данных (D :) (а не на томе, где расположены файлы журнала) ).

Объем данных и том журнала не являются общими дисками, однако они используют одну и ту же карту контроллера.

«Время простоя диска» мало для всех томов.

Есть, конечно, мысль, что карта контроллера может быть перегружена. Но нам нужно больше идей о том, где может быть проблема.

ОБНОВИТЬ:

RAID-контроллер - DELL PERC H700 (кэш 512 МБ). Сервер - это DELL R910.

У нас около 2500 транзакций в секунду в часы пик.

Счетчик "дискового времени" был на 100% с тех пор, как мы переместили файлы журнала (даже во время низкого трафика).

Однако "время простоя диска" составляет около 98-99% для D: (файлы данных) и E: (файлы журнала).

У нас включен кэш обратной записи для дисков данных и дисков журналов.

Статистика ожидания выглядит так:

wait_type                     wait_time_s
---------                     ----------- 
BROKER_TASK_STOP               1283336.21 
FT_IFTS_SCHEDULER_IDLE_WAIT     101357.47 
PAGELATCH_EX                     89712.72 
BROKER_TRANSMITTER               75894.76
XE_TIMER_EVENT                   38778.35
REQUEST_FOR_DEADLOCK_SEARCH      38770.35
SQLTRACE_INCREMENTAL_FLUSH_SLEEP 38767.03 
FT_IFTSHC_MUTEX                  38759.14
LOGMGR_QUEUE                     38632.87
CHECKPOINT_QUEUE                 38382.63
BROKER_EVENTHANDLER              35082.42   
XE_DISPATCHER_WAIT               34396.31  
DISPATCHER_QUEUE_SEMAPHORE       33578.68

После еще нескольких исследований (проверка ожидания и запуск сайта с пиковым трафиком) описанная выше «проблема» на самом деле не была проблемой.

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

Это также объясняет, почему время простоя диска было хорошим.

Счетчик "дискового времени" кажется бесполезным для быстрой дисковой системы (использующей кэш и т. Д.).