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

Автор: 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 и ушёл, а может, у вас есть свои причины, и они меня не касаются.

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

Но это не так.

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

Риски установки обновлений SQL Server: обновлять иль не обновлять - вот в чём вопрос

Автор: Steve Stedman, SQL Server Patching Risks: To Patch or Not to Patch?

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

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

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

Диагностика проблем производительности

Авторы: Сунил Агарвал (Sunil Agarwal), Борис Барышников (Boris Baryshnikov), Кит Элмор (Keith Elmore), Юрген Томас (Juergen Thomas), Кун Чен (Kun Cheng), Бурзин Патель (Burzin Patel)

Технические рецензенты: Жером Халманс (Jerome Halmans), Фабрисио Возника (Fabricio Voznika), Джордж Рейня (George Reynya)

Troubleshooting Performance Problems in SQL Server 2008

Краткое содержание: Иногда неправильно спроектированная база данных или система, неправильно настроенная под рабочую нагрузку, может вызывать замедление работы SQL Server. Администраторам необходимо активно предотвращать или минимизировать проблемы, а когда они возникают — диагностировать причину и принимать корректирующие меры. В этом документе содержатся пошаговые рекомендации по диагностике и устранению распространённых проблем производительности с использованием общедоступных инструментов, таких как SQL Server Profiler, Performance Monitor, динамические административные представления (DMV), а также расширенные события (Extended Events) и сборщик данных.