Запити вводу / виводу тривалістю більше 15 секунд

Зазвичай наші щотижневі повні резервні копії закінчуються приблизно за 35 хвилин, а щоденні різні резервні копії закінчуються за ~ 5 хвилин. З вівторка у щоденників пройшло майже 4 години, щоб пройти більше, ніж потрібно. Випадково це почалося відразу після того, як ми отримали новий конфігурацію SAN / диск.

Зауважте, що сервер працює у виробництві, і у нас немає загальних проблем, він працює безперебійно - за винятком проблеми IO, яка в першу чергу проявляється у продуктивності резервного копіювання.

Переглядаючи dm_exec_requests під час створення резервної копії, резервна копія постійно чекає ASYNC_IO_COMPLETION. Ага, значить, у нас дискусія про диск!

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

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

Раніше ми використовували рамки jumbo, але я відключив їх, щоб виключити будь-які проблеми тут - ніяких змін. У нас є ще один сервер (той же 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 / контролері, і з мого Googling вони здаються некритичними.

Зверніть увагу, що всі сервери використовують однакові NIC - Broadcom 5709C з сучасними драйверами. Самі сервери - це Dell R610.

Я не впевнений, що далі перевірити. Будь-які пропозиції?

Оновлення - Запуск парфмону
Я спробував записати Ср. Диск сек / читання та запис лічильників парфу при виконанні резервного копіювання. Резервне копіювання починається палаючим, а потім зупиняється мертвим на 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?
На підставі пропозицій Марка Сторі-Смітса та попереднього досвіду Кайла Брандца з NIC Broadcom я вирішив зробити кілька експериментів. Оскільки у нас є кілька активних шляхів, я міг відносно легко змінити конфігурацію NIC один за одним, не викликаючи відключень.

Вимкнення TOE та велике відправлення 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).

І як контроль, я відключив і TOE, і 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 NIC TCP Offload Engine викликав проблеми. Як тільки TOE був відключений, все працювало як шарм. Здогадуюсь, я більше не буду замовляти більше NIC-коди Broadcom.

Оновлення - вниз переходить на CIFS-сервер.
Сьогодні ідентичний та функціонуючий CIFS-сервер почав вивішувати запити вводу-виводу. На цьому сервері не працював SQL Server, просто звичайний Windows Web Server 2008 R2, що обслуговує спільні доступності через CIFS. Як тільки я відключив TOE на ньому, все повернулося до роботи.

Просто підтверджує, що я більше ніколи не буду використовувати TOE на широкомовному NIC, якщо я взагалі не можу уникнути широкомовної програми NIC.

Зверніть увагу, що всі сервери використовують однакові NIC - Broadcom 5709C з сучасними драйверами. Самі сервери - це Dell R610.

Кайл Брандт має думку про мережеві карти 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 не є ідеальним конфігурацією для файлів даних, на яких розміщуються.