Page Life Expectancy — это не то, что вы думаете…

Автор: Paul Randal, Page Life Expectancy isn’t what you think…

Существует много споров о счётчике производительности Buffer Manager — Page Life Expectancy, в основном вокруг того, что люди продолжают цитировать 300 в качестве порога для начала беспокойства о проблеме (что в наши дни является полной ерундой). Это слишком низкое значение, чтобы быть точкой, на которой стоит начинать беспокоиться, если ваш PLE падает и остаётся на этом уровне. Джонатан предложил лучшее число, основанное на размере вашего буферного пула — см. нижнюю часть его статьи здесь.

Но не поэтому я пишу сегодня: я хочу объяснить, почему в настоящее время Page Life Expectancy в большинстве случаев не даёт вам полезной информации.

Статистика ожиданий для одной операции

Автор: Paul Randal, Capturing wait stats for a single operation

Эта статья о настройке производительности, которая давно была в моём списке задач. Анализ статистики ожиданий — отличный способ изучить симптомы проблем с производительностью (см. мой каталог Wait Stats для получения дополнительной информации), но использование DMV sys.dm_os_wait_stats показывает всё, что происходит на сервере. Если вы хотите увидеть, какие ожидания возникают из-за одного запроса или операции в рабочей системе (например, влияние подсказок MAXDOP на количество и продолжительность ожиданий CXPACKET для запроса), то использование DMV обычно нецелесообразно — вам пришлось бы очистить статистику ожиданий и убедиться, что в системе не выполняется ничего, кроме исследуемого запроса/операции. Наиболее правильный способ сделать это — использовать расширенные события (Extended Events).

Проблемы производительности из-за неэффективного использования памяти буферного пула

Автор: Paul Randal, Performance issues from wasted buffer pool memory

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

Причина, по которой меня это интересует и должна интересовать вас, заключается в том, что память — один из важнейших ресурсов, используемых SQL Server. Если у вас недостаточно памяти, ваша рабочая нагрузка будет страдать, потому что:

• Вы будете выполнять больше операций чтения ввода-вывода, поскольку большая часть рабочей нагрузки не может поместиться в буферном пуле.
• Вы будете выполнять больше операций записи ввода-вывода, так как «ленивому писателю» (lazywriter) придётся вытеснять грязные страницы из буферного пула.
• Вы можете столкнуться с ожиданиями RESOURCE_SEMAPHORE, потому что запросы не могут получить необходимые им назначения памяти для выполнения запросов.
• Вы можете вызвать чрезмерное количество перекомпиляций планов, если кэш планов слишком ограничен.
• И целый ряд других проблем.

Одной из проблем с памятью, которую Кимберли подробно обсуждала в прошлом году (и подробно обучает этому на наших курсах по настройке производительности), является раздувание кэша однократно используемых планов (single-use plan cache bloat), когда большая часть кэша планов заполнена планами, которые используются один раз и никогда больше не пригодятся. Вы можете прочитать об этом в трёх постах в её категории Plan Cache, а также о том, как выявить раздувание кэша планов и что с этим можно сделать.

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

Структуры хранения #5 – XML-индексы

Автор: Hugo Kornelis, Storage structures 5 – XML indexes;

После рассмотрения дискового строчного хранения, индексов columnstore, оптимизированных для памяти структур и оптимизированных для памяти columnstore, пришло время обратить внимание на структуры хранения, которые используются только для определённых типов данных. Первой «жертвой» станет XML-индекс.

Ожидания SOS_SCHEDULER_YIELD и спин-блокировка LOCK_HASH

Автор: Paul Randal, SOS_SCHEDULER_YIELD waits and the LOCK_HASH spinlock

В этой статье я хотел бы показать пример возникновения ожиданий SOS_SCHEDULER_YIELD и того, как может показаться, что причиной является спин-блокировка.

Первоначально я опубликовал эту статью, а затем обсудил его с моим хорошим другом Бобом Уордом (Bob Ward) из службы поддержки продуктов, который усомнился в моих выводах, основываясь на своём опыте (спасибо, Боб!). После более глубокого исследования я обнаружил, что моя первоначальная версия была неверной, поэтому это исправленная версия.

Продвинутая настройка производительности SQL Server

Автор: Paul Randal, Advanced SQL Server performance tuning

Всё это прекрасно — иметь навороченные сторонние инструменты мониторинга и диагностики производительности, но иногда вам приходится углубляться в происходящее внутри SQL Server дальше, чем могут зайти эти инструменты. Или вам приходится обращаться в службу поддержки клиентов или Premier Support, чтобы они могли углубиться.

Обычно вы или они будете использовать четыре динамических административных представления (DMV), которые дают всё более продвинутую информацию о происходящем для диагностики производительности:

• sys.dm_os_wait_stats
• sys.dm_os_waiting_tasks
• sys.dm_os_latch_stats
• sys.dm_os_spinlock_stats (этот вообще не документирован и упоминается лишь в нескольких местах в Интернете)

В этой статье я немного объясню эти DMV, уделив основное внимание защёлкам (кратким блокировкам) и спин-блокировкам. 

Как исследовать задержки подсистемы ввода-вывода изнутри SQL Server

Автор: Paul Randal, How to examine IO subsystem latencies from within SQL Server

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

Оптимизация запросов: выражения в предложении WHERE, не допускающие поиска по индексу

Автор: Paul Randal, Adventures in query tuning: non-seekable WHERE clause expressions

За последние пару месяцев я выполнил много работы по настройке производительности, и в эти выходные обнаружил нечто, очень распространённое в реальных системах. Кимберли помогала мне оптимизировать один сложный план запроса и заметила в коде то, чего я не увидел, — это приводило к просмотру индекса вместо поиска по индексу. Несмотря на то, что план запроса использовал покрывающий некластерный индекс, способ написания кода заставлял индекс сканироваться.

Я подготовлю тестовый пример, чтобы показать, что я имею в виду.

Отслеживание тяжёлых запросов с помощью расширенных событий

Автор: Paul Randal, Tracking expensive queries with extended events in SQL 2008

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

Важные соображения при настройке производительности

Автор: Paul Randal, Important considerations when performance tuning

Что, по вашему мнению, является самым важным аспектом при настройке производительности, если бы пришлось выбрать что-то одно? Суть в том, что в общем случае ответ всегда «зависит», но некоторые вещи оказываются главной проблемой чаще, чем другие. Давайте пройдёмся по каждому возможному ответу и посмотрим, как сильно они могут повлиять на производительность, если что-то не так. Это ни в коем случае не исчерпывающий список того, что может вызвать проблемы, а просто мои размышления в конце воскресенья, как обычно.

Кластерный или некластерный индекс для случайного GUID?

Автор: Paul Randal, Clustered or nonclustered index on a random GUID?

Увидел вопрос на форуме: если я вынужден использовать GUID и обязан иметь первичный ключ, должен ли я сделать первичный ключ кластерным или некластерным?

Тут я не собираюсь вдаваться в дискуссию о GUID против bigint в качестве идентификатора, или о случайном GUID против GUID, генерируемого NEWSEQUENTIALID(), так что, пожалуйста, не комментируйте эти вопросы, здесь они не актуальны. Я просто хочу ответить на вопрос: каким должен быть этот индекс?

Перенос индексов в новую файловую группу: Microsoft по-прежнему вас хэйтит

Автор: Erik Darling, Moving Indexes To A New Filegroup: Microsoft Still Hates You

В какой-то момент вы захотите перенести некоторые индексы в новую файловую группу. Возможно, вы разделяете данные по разным хранилищам, возможно, вы наводите порядок после того, как кто-то поместил всё в PRIMARY и ушёл, а может, у вас есть свои причины, и они меня не касаются.

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

Но это не так.

Насколько всё плохо, зависит от того, что именно вы переносите. Давайте пройдёмся от наименее болезненного к самому болезненному, потому что боль здесь поучительна.