Запросы ввода / вывода занимают более 15 секунд

Обычно наши еженедельные полные резервные копии заканчиваются примерно за 35 минут, а ежедневные разностные резервные копии заканчиваются за ~ 5 минут. Со вторника ежедневные газеты заняли почти 4 часа, что намного больше, чем нужно. По совпадению, это начало происходить сразу после того, как мы получили новую конфигурацию SAN / диск.

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

Смотря на dm_exec_requests во время резервного копирования, резервное копирование постоянно ожидает ASYNC_IO_COMPLETION. Ага, значит у нас диск на споре!

Однако ни MDF (журналы хранятся на локальном диске), ни резервный диск не имеют никакой активности (IOPS ~ = 0 - у нас достаточно памяти). Длина очереди диска ~ = 0. Процессор зависает на 2-3%, проблем тоже нет.

SAN - это Dell MD3220i, LUN, состоящий из дисков SAS 6x10k. Сервер подключен к SAN через два физических пути, каждый из которых проходит через отдельный коммутатор с резервными подключениями к SAN - всего четыре пути, два из которых активны в любое время. Я могу проверить, что оба соединения активны через диспетчер задач - распределение нагрузки идеально равномерно. Оба соединения работают в режиме полного дуплекса 1G.

Мы привыкли использовать гигантские кадры, но я отключил их, чтобы исключить любые проблемы здесь - без изменений. У нас есть другой сервер (тот же OS + config, 2008 R2), который подключен к другим LUN, и он не показывает никаких проблем. Тем не менее, он не работает на SQL Server, а просто использует CIFS поверх них. Тем не менее, один из предпочтительных путей LUN находится на том же контроллере SAN, что и проблемные LUN, так что я также исключил это.

Выполнение нескольких тестов SQLIO (тестовый файл 10G), кажется, указывает на то, что IO является достойным, несмотря на проблемы:

sqlio -kR -t8 -o8 -s30 -frandom -b8 -BN -LS -Fparam.txt
IOs/sec:  3582.20
MBs/sec:    27.98
Min_Latency(ms): 0
Avg_Latency(ms): 3
Max_Latency(ms): 98
histogram:
ms: 0  1  2  3  4  5  6  7  8  9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24+
%: 45  9  5  4  4  4  4  4  4  3  2  2  1  1  1  1  1  1  1  0  0  0  0  0  2

sqlio -kW -t8 -o8 -s30 -frandom -b8 -BN -LS -Fparam.txt
IOs/sec:  4742.16
MBs/sec:    37.04
Min_Latency(ms): 0
Avg_Latency(ms): 2
Max_Latency(ms): 880
histogram:
ms: 0  1  2  3  4  5  6  7  8  9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24+
%: 46 33  2  2  2  2  2  2  2  1  1  1  1  0  0  0  0  0  0  0  0  0  0  0  1

sqlio -kR -t8 -o8 -s30 -fsequential -b64 -BN -LS -Fparam.txt
IOs/sec:  1824.60
MBs/sec:   114.03
Min_Latency(ms): 0
Avg_Latency(ms): 8
Max_Latency(ms): 421
histogram:
ms: 0  1  2  3  4  5  6  7  8  9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24+
%:  1  3 14  4 14 43  4  2  1  1  1  1  1  1  0  0  0  0  0  0  0  0  0  0  6

sqlio -kW -t8 -o8 -s30 -fsequential -b64 -BN -LS -Fparam.txt
IOs/sec:  3238.88
MBs/sec:   202.43
Min_Latency(ms): 1
Avg_Latency(ms): 4
Max_Latency(ms): 62
histogram:
ms: 0  1  2  3  4  5  6  7  8  9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24+
%:  0  0  0  9 51 31  6  1  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0

Я понимаю, что это не исчерпывающие тесты в любом случае, но они помогают мне понять, что это не полный мусор. Обратите внимание, что более высокая производительность записи обусловлена ​​двумя активными путями MPIO, тогда как при чтении будет использоваться только один из них.

Проверка журнала событий приложения выявляет события, подобные этим, разбросанные вокруг:

SQL Server has encountered 2 occurrence(s) of I/O requests taking longer than 15 seconds to complete on file [J:\XXX.mdf] in database [XXX] (150).  The OS file handle is 0x0000000000003294.  The offset of the latest long I/O is: 0x00000033da0000

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

Initiator sent a task management command to reset the target. The target name is given in the dump data.
Target did not respond in time for a SCSI request. The CDB is given in the dump data.

Это также происходит на не проблемном сервере CIFS, работающем на том же SAN / Controller, и, по моему мнению, они не являются критическими.

Обратите внимание, что все серверы используют одинаковые сетевые карты - Broadcom 5709C с современными драйверами. Сами серверы Dell R610.

Я не уверен, что проверить на следующее. Какие-либо предложения?

Обновление - Запустив perfmon,
я попытался записать Avg. Disk sec / Read & Write счетчики производительности при выполнении резервного копирования. Резервное копирование начинается молниеносно, а затем в основном останавливается на 50%, медленно ползет к 100%, но занимает в 20 раз больше времени, чем следовало бы.

Показывает, как используются оба SAN-пути, а затем отключаются.

Резервное копирование началось около 15:38:50 - обратите внимание, что все выглядит хорошо, а затем есть ряд пиков. Я не касаюсь записей, кажется, только чтение зависает.

Обратите внимание, что очень мало действий вкл / выкл, хотя производительность в самом конце.

Обратите внимание на максимум 12 секунд, хотя среднее значение в целом хорошее.

Обновление - резервное копирование на устройство NUL.
Чтобы изолировать проблемы с чтением и упростить процесс, я запустил следующее:

BACKUP DATABASE XXX TO DISK = 'NUL'

Результаты были точно такими же - начинается с пакетного чтения, а затем останавливается, время от времени возобновляя операции:

Обновление - IO киосков
я побежал запрос dm_io_virtual_file_stats от Джонатана Kehayias и Тед Kruegers книги (стр 29), в соответствии с рекомендациями Шон. Если посмотреть на верхние 25 файлов (по одному файлу данных - все результаты являются файлами данных), то кажется, что чтение хуже записи - возможно, потому, что записи идут непосредственно в кэш SAN, тогда как холодное чтение должно попадать на диск - хотя бы предположение ,

Обновление - статистика
ожидания. Я провел три теста, чтобы собрать статистику ожидания. Статистика ожидания запрашивается с использованием сценария Гленна Берри / Пола Рэндалса . И просто для подтверждения - резервное копирование выполняется не на ленту, а на iSCSI LUN. Результаты схожи с локальным диском, с результатами, аналогичными NUL-резервной копии.

Очистил статистику. Пробежал 10 минут, нормальная нагрузка:

Очистил статистику. Работал в течение 10 минут, нормальная загрузка + нормальное резервное копирование (не завершено):

Очистил статистику. Работал в течение 10 минут, нормальная загрузка + резервное копирование NUL (не завершено):

Обновление - Wtf, Broadcom?
Исходя из предложений Марка Стори-Смита и предыдущего опыта Кайла Брандта с сетевыми картами Broadcom, я решил провести некоторые эксперименты. Поскольку у нас есть несколько активных путей, я мог относительно легко изменить конфигурацию сетевых адаптеров один за другим, не вызывая никаких сбоев.

Отключение TOE и Large Send Offload дало почти идеальный прогон:

Processed 1064672 pages for database 'XXX', file 'XXX' on file 1.
Processed 21 pages for database 'XXX', file 'XXX' on file 1.
BACKUP DATABASE successfully processed 1064693 pages in 58.533 seconds (142.106 MB/sec).

Так кто же виновник, TOE или LSO? TOE включен, LSO отключен:

Didn't finish the backup as it took forever - just as the original problem!

TOE отключен, LSO включен - выглядит хорошо:

Processed 1064680 pages for database 'XXX', file 'XXX' on file 1.
Processed 29 pages for database 'XXX', file 'XXX' on file 1.
BACKUP DATABASE successfully processed 1064709 pages in 59.073 seconds (140.809 MB/sec).

И в качестве контроля я отключил как ОО, так и LSO, чтобы подтвердить, что проблема исчезла:

Processed 1064720 pages for database 'XXX', file 'XXX' on file 1.
Processed 13 pages for database 'XXX', file 'XXX' on file 1.
BACKUP DATABASE successfully processed 1064733 pages in 60.675 seconds (137.094 MB/sec).

В заключение кажется, что включенный механизм Broadcom TCP Offload Engine вызвал проблемы. Как только ОО был отключен, все работало как шарм. Думаю, я не буду больше заказывать сетевые карты Broadcom.

Обновление - Вниз идет сервер CIFS
Сегодня на идентичном и работающем сервере CIFS начали появляться зависания запросов ввода-вывода. На этом сервере не был запущен SQL Server, просто Windows Web Server 2008 R2, обслуживающий общие ресурсы через CIFS. Как только я отключил TOE, все вернулось к нормальной работе.

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

Обратите внимание, что все серверы используют одинаковые сетевые карты - Broadcom 5709C с современными драйверами. Сами серверы Dell R610.

У Кайла Брандта есть мнение о сетевых картах Broadcom, которое перекликается с моим (повторным) опытом.

Broadcom, Die Mutha

Мои проблемы всегда были связаны с функциями TCP Offload, и в 99% случаев отключение или переключение на другую сетевую карту разрешило симптомы. Один клиент, который (как в вашем случае) использует серверы Dell, всегда заказывает отдельные сетевые адаптеры Intel и отключает встроенные платы Broadcom при сборке.

Как описано в этом сообщении в блоге MSDN , я бы начал с отключения в ОС с помощью:

netsh int ip set chimney DISABLED

IIRC в некоторых случаях может потребоваться отключить функции на уровне драйвера карты, это, безусловно, не помешает.

Не то, чтобы я был экспертом по SAN / диску (здесь есть люди, которые знают больше, чем я) ... Я делюсь только тем, что немного сделал и читаю :)

Джонатан Кехайас и Тед Крюгер написали книгу «Устранение неполадок с SQL Server», в которой содержится хорошая информация о производительности диска. Вы можете получить PDF бесплатно здесь . (Я мог бы купить печатное издание этого также для моего стола.)

В любом случае у них есть хороший запрос, который можно использовать для проверки sys.dm_io_virtual_file_stats и проверки средней задержки в ваших файлах данных. Вы можете обнаружить, что RAID10 - не идеальная конфигурация для файлов данных, на которых они находятся.