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, 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) и сборщик данных.

Логика принятия решения о размещении параллельных запросов в SQL Server

Автор: 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 (т.е. без какого-либо простоя приложения).

Как выбор типа данных влияет на производительность

Автор: Paul Randal, How can data-type choice affect performance?

На одном из занятий, которые мы с Кимберли вели на этой неделе на конференции SQL Connections, мы обсуждали, как выбирать эффективные типы данных. Я хотел бы поделиться этим обсуждением здесь на примере.

Проверка распределений памяти за 45 секунд: от симптомов к первопричине

Автор: Luca Biondi, Check Memory Grants in 45 Seconds. From Symptoms to Root Clause. The "45 Seconds DBA Series" – What Real DBAs Check First | Part 6

Распределения памяти (memory grants) — это молчаливые убийцы конкурентности в SQL Server. В этой статье я покажу вам, как выявить запросы, пожирающие память, и устранить катастрофические ожидания типа RESOURCE_SEMAPHORE всего за 45 секунд — до того, как ваш сервер полностью остановится!

В двух словах

• ✔️ Распределения памяти предназначены для сортировки и хэширования: Это рабочая область оперативной памяти (workspace RAM), полностью отделённая от буферного пула, который кэширует страницы данных. 🛠️
• ✔️ Ожидания RESOURCE_SEMAPHORE: Главный красный флаг, указывающий на то, что запросы выстраиваются в очередь, испытывая голод по исполнительной памяти. 💣
• ✔️ Выявление виновников: Используйте sys.dm_exec_query_memory_grants, чтобы мгновенно обнаружить запросы, требующие непомерно больших, неоправданных объёмов оперативной памяти. 🧪
• ✔️ Устранение первопричины: В 99% случаев раздувание памяти вызвано устаревшей статистикой или плохим индексированием, а не недостатком физической оперативной памяти на сервере. ✔️

Сталкивались ли вы когда-нибудь со сценарием, когда ваш процессор практически простаивает, дисковый ввод-вывод находится в норме, но пользовательские приложения повсеместно завершаются по тайм-ауту? Добро пожаловать в ужасное узкое место RESOURCE_SEMAPHORE. Это происходит, когда ваш экземпляр исчерпывает рабочую область памяти для выполнения запросов. Давайте разберём, как диагностировать и исправлять проблемы с распределением памяти — от симптомов до первопричин — менее чем за минуту!

Проверка нагрузки на память за 45 секунд

Автор: Luca Biondi, Check Memory Pressure in 45 Seconds. The "45 Seconds DBA Series" – What Real DBAs Check First | Part 4

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

В двух словах

• ✔️ Уровень ОС: Проверьте доступную физическую память – внешнее давление опасно 🛠️
• ✔️ PLE (Page Life Expectancy – ожидаемая продолжительность жизни страницы): Высокое значение – это хорошо, но внезапные падения означают активное перемещение данных в памяти (churn) 📉
• ✔️ Распределения памяти (Memory Grants): Долгие ожидания и огромные объёмы выделенной памяти – чистые убийцы параллелизма ⏳
• ✔️ Менеджеры памяти (Memory Clerks): Найдите, какой именно кэш (CACHESTORE, USERSTORE) ворует вашу оперативную память 🧠

В продолжение темы о промежуточной материализации (сбросе) в TempDB

Автор: Luca Biondi, Why SQL Server Starts Spilling to TempDB

Как мы говорили в предыдущей статье: когда загрузка ЦП в порядке, операции ввода-вывода в порядке, а запросы выглядят «нормально», но производительность нестабильна: иногда быстро, иногда медленно – настоящая проблема часто кроется в сбросах в TempDB. В этой второй части мы глубже разберём первопричину!

Потребление памяти запросами в SQL Server 2025

Автор: SQLYARD, SQL Query Memory Consumption in SQL Server 2025

Распределение памяти (memory grants) под запросы — один из ключевых и при этом часто недооцениваемых аспектов настройки производительности SQL Server. Если запрос просит больше памяти, чем ему нужно, падает параллелизм. Если слишком мало — происходят проливы в tempdb.

В SQL Server 2025 Microsoft улучшила обратную связь по распределению памяти запроса (query memory grant feedback) и оптимизацию планов выполнения, благодаря чему движок управляет памятью заметно эффективнее, чем в SQL Server 2022. В этой статье мы рассмотрим, как эти изменения влияют на производительность запросов, сравним уровни совместимости 160 и 170.

Hyper‑V и SQL Server: лучшие практики, о которых нам хочется, чтобы вы знали

Автор: Mike Walsh, Hyper-V and SQL Server Best Practices: What We Wish You Knew

Если вы когда‑нибудь задавались вопросом: «Почему 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» нескольких лет назад, мне гораздо приятнее, когда вы сами находите и исправляете эти моменты, а уж потом зовёте нас для действительно интересных и нетривиальных задач!

SQL Server и большие страницы: подробное объяснение

Автор: Bob Ward, SQL Server and Large Pages Explained

В на Europe PASS Summit я читал доклад о диагностике памяти. В нём упомянул, что SQL Server будет использовать большие страницы (Large Pages), если включён trace flag 834. На конференции Кристиан Болтон, хорошо известный MVP из Великобритании, заметил, что видел в ERRORLOG сообщения о «large pages», хотя trace flag у него был выключен. Тогда я ответил, что не представляю, как такое возможно. Что ж, Кристиан, вы ничего не выдумали.

Вскоре тема всплыла снова, когда я помогал коллегам из CSS разбираться с тем же вопросом. Самое время углубиться и разобраться, что же там на самом деле происходит.

Новое в SQL Server 2025: sys.dm_os_memory_health_history

Автор: SQLYARD, Meet sys.dm_os_memory_health_history in SQL Server 2025

В SQL Server 2025 компания Microsoft представила новое динамическое административное представление (DMV) sys.dm_os_memory_health_history. Ключевые моменты:

• Оно фиксирует снимки состояния использования и «здоровья» памяти во времени.
• Каждая строка — это один снимок.
• Снимки содержат различные метрики: сколько памяти доступно для новых распределений, сколько используется освобождаемыми кешами, какие диспетчеры памяти потребляют больше всего, а также «уровень серьёзности», показывающий, насколько здоровым (или перегруженным) является состояние памяти.
• Это функция в режиме предварительного просмотра — схема или поведение могут измениться в будущих обновлениях SQL Server 2025. 

Новое в SQL Server 2022: улучшаем масштабируемость с Buffer Pool Parallel Scan

Автор оригинала: David Pless. Principal Program Manager, Microsoft

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

Настройка Windows Server 2008/2003 x64 для обслуживания SQL Server 2008

По состоянию на 2009 год

Эта статья - вольная интерпретация рекомендаций: Microsoft, IBM, HP, Dell, QLogic, LSI, EMC, ACER, Bull, Fujitsu, Hitachi, NEC и Unisys. Некоторые рекомендуемые настройки требуют отдельного, обстоятельного разговора, и потому не включены в эту статью, а найти эти рекомендации можно в этом блоге.

Пример настройки Soft-NUMA

Сегодня получили широкое распространение многоядерные системы. Персональные компьютеры с четырьмя ядрами уже не редкость. Т.о. счастливые обладатели подобных многоядерных систем могут на практическом примере апробировать Soft-NUMA и как можно привязать к Soft-NUMA узлу порт сетевого протокола TCP/IP.

Tips for DBA: Экспресс-диагностика достаточности памяти системе и экземпляру SQL Server

По ссылке в сценарии можно найти статью, которая меня вдохновила написать пример сценария, который может оказаться полезным для экспресс-диагностики проблем распределения оперативной и виртуальной памяти для нужд запрашиваемого экземпляра SQL Server и операционной системы. Я оставил только реальные (как мне думается) сценарии, которые могут случиться с памятью. Прогон на моих серверах вроде показал правдивость обнаруженного. Посмотрите у себя? Обсудить результаты и сам сценарий можно в коментариях.

Running SQL Server on Machines with More Than 8 CPUs per NUMA Node May Need Trace Flag 8048

По материалам статьи: Running SQL Server on Machines with More Than 8 CPUs per NUMA Node May Need Trace Flag 8048

Данная статья относится к следующим версиям SQL Sever: 2008, 2008 R2, 2012 и 2014. Первый вариант статьи был опубликован в 2011г.

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

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

Tips for DBA: Оповещение о новых дампах SQL Server

Не существует рекомендованного Майкрософт способа уведомления администраторов о том, что SQL Server выгрузил дамп страниц памяти на диск. Также весьма затруднительно отслеживать такие дампы средствами SQL Server или операционной системы, поскольку во время выгрузки дампа работа сервера баз данных и большинства системных процессов «замирает». Однако, вполне возможно обнаружить последствия выгрузки дампа, поскольку в указанной для дампов папке вместе с файлами дампа появится файл с именем: «SQLDUMPER_ERRORLOG.log». Имя этого файла неизменно, на этом и основан предлагаемый вашему вниманию способ слежений за появлением новых дампов. Настройка пути к папке дампов хранится в системном реестре. По этому пути можно посредством PowerShell узнать существует ли в папке дампов файл с именем «SQLDUMPER_ERRORLOG.log». Такую проверку можно делать по расписанию в задании Агента SQL Server. Если файл обнаружен, то можно совершить необходимое действие. Например, в приведенном ниже сценарии будет отправлено письмо электронной почты на указанный список адресов. Отправку осуществит подсистема SQL Server DatabaseMail. Для корректной отправки сообщения нужно указать существующий почтовый профиль.

SQL Server 2012 Database Engine Task Scheduling

Дата публикации: 13 августа 2013г.

Автор: Боб Дорр – главный эскалационный инженер поддержки SQL Server
По материалам статьи: How It Works: SQL Server 2012 Database Engine Task Scheduling

В течении последних лет в разных источниках были описаны алгоритмы работы планировщика SQL Server. В частности, в статье «The Guru’s Guide to SQL Server Architecture and Internals» есть глава, написанная разработчиком планировщика (Sameer) и Кеном Хендерсеном. Автор этой статьи иранее описывал некоторые технические детали алгоритмов планирования задач SQLServer.

Эта статья посвящена некоторым изменениям, которые появились в SQL Server 2012. Статья не претендует на охват всех нюансов (коих слишком много), вместо этого будет частично проиллюстрирована работа алгоритма в его современной реализации, что позволит вам лучше понимать поведение планировщика SQLServer . Автор допускает по тексту несколько вольную трактовку в описании алгоритмов, преследуя цель избавить статью от лишней официальности.