Какая частота разливов хеша / сортировки в базу данных tempdb?

Наше корпоративное приложение использует SQL Server для хранения данных и в основном представляет собой систему OLTP. Однако важный компонент нашего приложения создает значительную рабочую нагрузку OLAP.

Наша задержка записи в tempdb составляет около 100 мс. Эта тенденция имеет место в течение долгого времени, и ALLOW_SNAPSHOT_ISOLATIONповернута от . Мы устраняем эту проблему, и единственная интересная вещь, которую мы обнаружили на данный момент, заключается в том, что в базу данных tempdb добавлено значительное количество хешей и различий. Мы предполагаем, что это связано с нашей рабочей нагрузкой OLAP.

Вопрос

Какова частота разливов? Любой? Сколько разливов в секунду? Наши предварительные данные показывают, что у нас есть около 2 разливов хеша в секунду и 25 разливов сортировки в минуту.

Возможно ли, что эта частота разливов может быть основной причиной нашей высокой задержки записи в tempdb?

Дополнительная информация

Мы используем несколько файлов для базы данных tempdb в соответствии с рекомендациями на количество ядер. Файлы tempdb находятся в RAID 1 + 0 SAN (с высокопроизводительными твердотельными накопителями), но это то же устройство, что и файлы основной базы данных и файлы журналов. Файлы tempdb имеют достаточно большой размер, поэтому они растут очень редко. Мы не используем флаги трассировки 1117 или 1118. Другая переменная заключается в том, что эта настройка является общей для ряда различных баз данных, которые испытывают среднюю и высокую нагрузку.

Наша задержка записи в 100 мс намного превышает допустимые диапазоны задержки записи в базу данных tempdb, которые мы обнаружили на MSDN, навыках SQL и других сайтах. Однако задержка записи для других наших баз данных хорошая (менее 10 мс). Судя по другим характеристикам, похоже, что мы интенсивно используем tempdb, особенно для внутренних объектов. Поэтому мы копаемся, чтобы выяснить, почему наше приложение так интенсивно использует внутренние объекты.

У нас действительно есть проблемы с производительностью на нашей платформе, которые проявляются по-разному. Мы отслеживали счетчики производительности, просматривали представления DM и анализировали поведение нашего приложения, чтобы попытаться вникнуть в характеристики использования ресурсов нашей системы. Мы сосредоточены на разливах прямо сейчас, поскольку мы прочитали, что разливы имеют радикальное негативное влияние, потому что они выполняются на диске, а не в памяти. И у нас, похоже, очень много разливов, но я хотел получить некоторую информацию о том, что люди считают «высоким».

Возможно ли, что эта частота разливов может быть основной причиной нашей высокой задержки записи в tempdb?

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

SQL Server предоставляет широкий спектр метрик и информации DMV, чтобы помочь вам устранить различные факторы, способствующие давлению tempdb, многие из которых обсуждаются в технической статье Microsoft «Работа с tempdb в SQL Server 2005» (относится ко всем версиям 2005 года и более поздним версиям). ).

Вы должны быть в состоянии использовать указания и диагностические запросы, содержащиеся в этом документе, чтобы начать определять основные причины любого давления на базу данных tempdb. Не игнорируйте, например, активность хранилища версий просто потому, что ALLOW_SNAPSHOT_ISOLATIONона не включена. Многие функции используют хранилище версий (например, триггеры, MARS, RCSI) помимо изоляции моментальных снимков.

Если результаты сортировки и хэширования окажутся значительными на высоком уровне, вам, вероятно, потребуется настроить какой-то конкретный мониторинг для этого. В зависимости от версии SQL Server, это не всегда просто, как можно было бы надеяться. Чтобы связать сортировку и выбросы хеша с конкретным запросом, который их вызвал, требуются уведомления о событиях или расширенные события. Статья SolidQ « Выявление и устранение предупреждений сортировки » содержит подробности и некоторые полезные общие советы по устранению распространенных причин.

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