Увеличение времени ожидания во время проверки после обновления до лучшего хранилища

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

Версия: SQL Server 2012 Sp4

В нашем старом хранилище наши ожидания составляли около 2 тыс. С «шипами» до 2500 во время контрольной точки, а в новом хранилище пики обычно составляют 10 тыс. С пиками около 50 тыс. Часовой указывает нам больше на PAGEIOLATCHУотиса. Делая наш собственный анализ, кажется, что это комбинация PAGEIOLATCH and PAGELATCHожиданий. Используя Perfmon, мы, как правило, можем сказать, что чем больше страниц мы проверяем, тем больше ожидаем получаемых результатов, но во время проверки мы сбрасываем всего ~ 125 мб. Наша рабочая нагрузка в основном пишет (в первую очередь вставляет / обновляет).

Поставщик хранилища доказал нам, что массив прямого подключения Fibre Channel отвечает менее 1 мс во время этих событий контрольной точки. HBA также подтверждает номера массива. Мы также не считаем, что это проблема очередей HBA, поскольку глубина очереди никогда не превышала 8. Мы также попробовали более новую HBA, изменив настройки ZIO, газа выполнения и глубины очереди безрезультатно. Мы также увеличили объем памяти сервера с 500 ГБ до 1 ТБ без изменений. Во время процесса проверки мы видим, что 2 - 4 отдельных ядра (из 16) имеют скачок до 100%, но общий процессор составляет около 20%. BIOS также настроен на высокую производительность. Интересно, что мы видим, что процессоры, как правило, находятся в состоянии сна C2, хотя мы это отключили, поэтому мы все еще исследуем, почему состояние сна проходит после C1.

Мы можем видеть, что почти все ожидания находятся на страницах данных со случайным PFS типа страницы DCM. Ожидания в пользовательских БД, а не в tempdb. Мы также видим, что ожидания находятся на нескольких страницах данных, а некоторые SPID ожидают на одной странице. Проект базы данных имеет несколько горячих точек вставки, но тот же дизайн был на месте со старым хранилищем.

Запустив цикл этого запроса 100 раз, мы смогли определить, сколько SPID ожидали на диске и в памяти.

SELECT
    [owt].[wait_type], count(*) as waitcount
FROM sys.dm_os_waiting_tasks [owt]
WHERE [owt].[wait_type] LIKE 'PAGE%'
group by [owt].[wait_type]
order by 1
GO 100

Приятно то, что мы можем легко воспроизвести проблему в нашей среде Perf, которая имеет тот же массив моделей и схожие спецификации сервера. Буду признателен за любые мысли о том, где еще искать или как сузить проблему. Прямо сейчас наши следующие тесты включают в себя: новый сервер с новой материнской платой и большим количеством процессоров; отключение SIOS datakeeper (даже если это было в прежнем хранилище); другой бренд HBA.

exec sp_Blitz @outputtype = 'markdown'

Приоритет 5: Надежность : - Опасные модули сторонних производителей - Sophos Limited - Защита от переполнения буфера Sophos - SOPHOS ~ 2.DLL - предположительно установлен опасный модуль сторонних производителей.

Приоритет 200: информационный : - узел кластера - это узел в кластере. - TraceFlag On - Флаг трассировки 1117 включен глобально. - Флаг трассировки 1118 включен глобально. - Флаг трассировки 3226 включен глобально.

Приоритет 200: Лицензирование : - Используемые функции Enterprise Edition * xxxxx - База данных [xxxxxx] использует сжатие. Если эта база данных восстановлена ​​на сервере Standard Edition, восстановление завершится неудачно в версиях до 2016 SP1. * xxxxx - База данных [xxxxxx] использует Partitioning. Если эта база данных восстановлена ​​на сервере Standard Edition, восстановление завершится неудачно в версиях до 2016 SP1.

Приоритет 240: Статистика ожидания: - Значительных ожиданий не обнаружено - Возможно, этот сервер просто бездействует, или кто-то недавно очистил статистику ожидания.

Приоритет 250: Информация о сервере: - Аппаратное обеспечение - Логические процессоры: 16. Физическая память: 512 ГБ. - Оборудование - NUMA Config - Узел: 0 Состояние: ONLINE Онлайн-планировщики: 8 Автономные планировщики: 0 Группа процессоров: 0 Узел памяти: 0 Память VAS Зарезервировано ГБ: 1177 - Узел: 1 Состояние: ONLINE Онлайн-планировщики: 8 Автономные планировщики: 0 Процессор Группа: 0 Узел памяти: 1 Память VAS зарезервировано ГБ: 0 - План энергопотребления - Ваш сервер имеет процессоры с частотой 3,50 ГГц и находится в режиме высокой производительности - Последний перезапуск сервера - 4 июля 2018 4:56 - Последний перезапуск SQL Server - 5 июля 2018 5:11 - Служба SQL Server - Версия: 11.0.7462.6. Уровень патча: SP4. Редакция: Enterprise Edition (64-разрядная версия). Группы доступности включены: 1. Статус диспетчера групп доступности: 1 - Виртуальный сервер - Тип: (HYPERVISOR) - Версия Windows - Вы используете довольно современную версию Windows: Server 2012R2 эра, версия 6.3

Приоритет 200: настройка сервера не по умолчанию: - Агент XP - эта опция sp_configure была изменена. Его значение по умолчанию равно 0, и оно было установлено на 1. - резервное сжатие по умолчанию - этот параметр sp_configure был изменен. Его значение по умолчанию равно 0, и оно было установлено равным 1. - Порог (ы) заблокированных процессов - эта опция sp_configure была изменена. Его значение по умолчанию равно 0, и было установлено значение 20. - порог стоимости для параллелизма - эта опция sp_configure была изменена. Его значение по умолчанию - 5, и было установлено значение 30. - Database Mail XPs - этот параметр sp_configure был изменен. Его значение по умолчанию равно 0, и оно установлено в 1. - максимальная степень параллелизма - эта опция sp_configure была изменена. Его значение по умолчанию равно 0, и оно было установлено равным 8. - максимальная память сервера (МБ) - эта опция sp_configure была изменена. Его значение по умолчанию - 2147483647, и оно было установлено на 496640. - минимальная память сервера (МБ) - этот параметр sp_configure был изменен. Его значение по умолчанию равно 0, и оно было установлено на 8196. - оптимизировать для специальных рабочих нагрузок - эта опция sp_configure была изменена. Его значение по умолчанию равно 0, и оно было установлено на 1. - удаленный доступ - эта опция sp_configure была изменена. Его значение по умолчанию равно 1, и оно было установлено равным 0. - Удаленные подключения администратора - эта опция sp_configure была изменена. Его значение по умолчанию равно 0, и оно было установлено на 1. - проверять наличие процедур запуска - эта опция sp_configure была изменена. Его значение по умолчанию равно 0, и оно было установлено на 1. - показать расширенные параметры - этот параметр sp_configure был изменен. Его значение по умолчанию равно 0, и оно было установлено на 1. - xp_cmdshell - этот параметр sp_configure был изменен.

Хм. Вы показываете паузы в ожидании во время контрольной точки, но не как долго ждать в среднем / в совокупности (что, честно говоря, это все, что меня волнует). Проведите дифференциальный анализ статистики ожидания, чтобы увидеть, имеет ли значение продолжительность. Кроме того, что именно два ожидания на вашем графике? Если вы получаете много памяти, ожидающей с 1 ТБ оперативной памяти, нам нужно провести другое обсуждение. :-D

Скорость записи 125 МБ во время контрольной точки: это ПРОСТО пишет контрольная точка или ВСЕ? В любом случае это кажется низким для хранения на всех флеш-накопителях. Вы тестировали хранилище для различных шаблонов записи, и если да, то какие числа вы получили?

Мы не уверены, почему изменилось поведение нашего SQL Server (и у нас есть доказательства того, что это произошло до переключения хранилища), но включение косвенных контрольных точек для пользовательских БД устранило проблему для нас.