Кеш планов SQL Server — это критически важный компонент, который хранит планы выполнения запросов для повторного использования. Однако неправильное использование этого механизма может привести к серьезным проблемам производительности. В этой статье мы рассмотрим:
Автор: Paul Randal, Page Life Expectancy isn’t what you think…
Существует много споров о счётчике производительности Buffer Manager — Page Life Expectancy, в основном вокруг того, что люди продолжают цитировать 300 в качестве порога для начала беспокойства о проблеме (что в наши дни является полной ерундой). Это слишком низкое значение, чтобы быть точкой, на которой стоит начинать беспокоиться, если ваш PLE падает и остаётся на этом уровне. Джонатан предложил лучшее число, основанное на размере вашего буферного пула — см. нижнюю часть его статьи здесь.
Но не поэтому я пишу сегодня: я хочу объяснить, почему в настоящее время Page Life Expectancy в большинстве случаев не даёт вам полезной информации.
Автор: Paul Randal, Important considerations when performance tuning
Что, по вашему мнению, является самым важным аспектом при настройке производительности, если бы пришлось выбрать что-то одно? Суть в том, что в общем случае ответ всегда «зависит», но некоторые вещи оказываются главной проблемой чаще, чем другие. Давайте пройдёмся по каждому возможному ответу и посмотрим, как сильно они могут повлиять на производительность, если что-то не так. Это ни в коем случае не исчерпывающий список того, что может вызвать проблемы, а просто мои размышления в конце воскресенья, как обычно.
Авторы: Сунил Агарвал (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) и сборщик данных.
Автор: Bob Dorr - MS Principal SQL Server Escalation Engineer, SQL Server Parallel Query Placement Decision Logic
Недавно у меня состоялся разговор с Jonathan Kehayias из sqlskills.com о размещении рабочих потоков, принадлежащих параллельному запросу. Когда я расспрашивал людей и изучал код, я быстро обнаружил, что предположение всё ещё заключается в том, что используется «наименее загруженный узел» (Least Loaded Node), но это изменилось в SQL Server 2012, и осведомлённость об этом как у наших инженеров поддержки, так и у клиентов оставляет желать лучшего. В этой статье я освещаю различные варианты решений, доступные SQL Server 2012, 2014 и 2016.
Автор: Paul Randal, SQL Server 2008: Hot-Add CPU (and affinity masks)
Короткая заметка сегодня, так как я готовлюсь к выступлению на собрании пользовательской группы SQL Server в Тихоокеанском Северо-Западе сегодня вечером в кампусе Microsoft в Редмонде.
SQL Server 2005 представил концепцию горячего добавления памяти (hot-add memory) для динамической обработки рабочей нагрузки. SQL Server 2008 расширяет эти возможности, добавляя также горячее добавление ЦП (hot-add CPU). Начиная с SQL Server 2025 (17.x), функция горячего добавления ЦП не рекомендуется и планируется удалить в будущей версии SQL Server. «Горячее добавление» означает возможность установить ЦП в работающую машину и затем перенастроить SQL Server для использования этого ЦП ONLINE (т.е. без какого-либо простоя приложения).
На одном из занятий, которые мы с Кимберли вели на этой неделе на конференции SQL Connections, мы обсуждали, как выбирать эффективные типы данных. Я хотел бы поделиться этим обсуждением здесь на примере.
Распределения памяти (memory grants) — это молчаливые убийцы конкурентности в SQL Server. В этой статье я покажу вам, как выявить запросы, пожирающие память, и устранить катастрофические ожидания типа RESOURCE_SEMAPHORE всего за 45 секунд — до того, как ваш сервер полностью остановится!
sys.dm_exec_query_memory_grants, чтобы мгновенно обнаружить запросы, требующие непомерно больших, неоправданных объёмов оперативной памяти. 🧪Сталкивались ли вы когда-нибудь со сценарием, когда ваш процессор практически простаивает, дисковый ввод-вывод находится в норме, но пользовательские приложения повсеместно завершаются по тайм-ауту? Добро пожаловать в ужасное узкое место RESOURCE_SEMAPHORE. Это происходит, когда ваш экземпляр исчерпывает рабочую область памяти для выполнения запросов. Давайте разберём, как диагностировать и исправлять проблемы с распределением памяти — от симптомов до первопричин — менее чем за минуту!
В этой статье я покажу вам свой диагностический план из 5 шагов для выявления губительной нагрузки на память SQL Server менее чем за 45 секунд. Перестаньте гадать и начните точно определять, что именно лишает ваш буферный пул памяти, прежде чем производительность полностью деградирует!
Как мы говорили в предыдущей статье: когда загрузка ЦП в порядке, операции ввода-вывода в порядке, а запросы выглядят «нормально», но производительность нестабильна: иногда быстро, иногда медленно – настоящая проблема часто кроется в сбросах в TempDB. В этой второй части мы глубже разберём первопричину!
Распределение памяти (memory grants) под запросы — один из ключевых и при этом часто недооцениваемых аспектов настройки производительности SQL Server. Если запрос просит больше памяти, чем ему нужно, падает параллелизм. Если слишком мало — происходят проливы в tempdb.
В SQL Server 2025 Microsoft улучшила обратную связь по распределению памяти запроса (query memory grant feedback) и оптимизацию планов выполнения, благодаря чему движок управляет памятью заметно эффективнее, чем в SQL Server 2022. В этой статье мы рассмотрим, как эти изменения влияют на производительность запросов, сравним уровни совместимости 160 и 170.
Если вы когда‑нибудь задавались вопросом: «Почему SQL Server на Hyper‑V работает медленнее, чем должен?!», эта заметка может помочь. И да, если бы десять лет назад вы спросили меня о Hyper‑V, я бы, вероятно, лишь усмехнулся. Может, и раньше. Но суть в том, что эта платформа масштабируется, работает, и на фоне «весёлых» нововведений Broadcom/VMware (с соответствующей монетизацией), всё больше клиентов переходят на Hyper‑V. Как и с VMware, здесь важно внимательно отнестись к ряду ключевых настроек.
Спасибо Jeff Iannucci за совместную работу над этой статьёй и за его идеи. Он слишком долго напоминал мне подготовить этот пост и чек‑лист для клиентов — в итоге решил помочь и с написанием.
Мы в Straight Path в основном команда DBA, но нас часто просят помочь с развёртыванием SQL Server на виртуальных машинах Hyper‑V и спрашивают: «Каковы лучшие практики?». Многие (если не большинство) системных администраторов это всё и так знают. Но если вдруг нет, или если в вашей компании «все шляпы» приходится носить вам одному, мы собрали ключевые рекомендации, которые помогут обеспечить высокую доступность и стабильную производительность SQL Server на Hyper‑V.
Это не тайные знания. Но это те вещи, упущенные настройки и неверные решения, которые мы продолжаем встречать на практике, работая с новыми клиентами. И как в нашей статье «VMware and SQL Server best practices» нескольких лет назад, мне гораздо приятнее, когда вы сами находите и исправляете эти моменты, а уж потом зовёте нас для действительно интересных и нетривиальных задач!
В на Europe PASS Summit я читал доклад о диагностике памяти. В нём упомянул, что SQL Server будет использовать большие страницы (Large Pages), если включён trace flag 834. На конференции Кристиан Болтон, хорошо известный MVP из Великобритании, заметил, что видел в ERRORLOG сообщения о «large pages», хотя trace flag у него был выключен. Тогда я ответил, что не представляю, как такое возможно. Что ж, Кристиан, вы ничего не выдумали.
Вскоре тема всплыла снова, когда я помогал коллегам из CSS разбираться с тем же вопросом. Самое время углубиться и разобраться, что же там на самом деле происходит.
В SQL Server 2025 компания Microsoft представила новое динамическое административное представление (DMV) sys.dm_os_memory_health_history. Ключевые моменты:
Эта статья - вольная интерпретация рекомендаций: Microsoft, IBM, HP, Dell, QLogic, LSI, EMC, ACER, Bull, Fujitsu, Hitachi, NEC и Unisys. Некоторые рекомендуемые настройки требуют отдельного, обстоятельного разговора, и потому не включены в эту статью, а найти эти рекомендации можно в этом блоге.
Данная статья относится к
следующим версиям SQL Sever: 2008, 2008 R2, 2012 и 2014. Первый вариант статьи
был опубликован в 2011г.
Примечание: в данной статье
под количеством процессоров подразумеваются не сокеты, а представленные в
системе логические процессоры. Рекомендации статьи применимы в тех случаях,
когда для сервера баз данных доступно более восьми логических процессоров.
В зависимости от того, для каких нужд SQL Server использует память, дизайн ядра сервера баз данных предусматривает возможность секционирования распределения памяти. В процессе разработки SQL Server можно было выбирать схему секционирования исполнителя по процессорам, узлам или глобально. Некоторые связанные с распределением памяти функциональные модули SQL Server используют модуль распределения CMemPartitioned. Этот модуль секционирует память по процессорам или NUMA узлам, что может способствовать повышению параллелизма и производительности.
