Для анализа статистики ожиданий необходимо собирать эту статистику в то время, в которое проявляются проблемы, либо обслуживается нагрузка, которую необходимо исследовать. Для этого обращение непосредственно к sys.dm_os_wait_stats не очень подходит, т.к. там накоплена статистика с момента последнего запуска сервера, либо с момента последней очистки результатов динамического представления командой: DBCC SQLPERF ('sys.dm_os_wait_stats', CLEAR);
Известны несколько статей об обнаружении проблем ввода-вывода, связанных с SQL Server. Существуют разные методы поиска «узких мест» ввода-вывода, мы же сконцентрируемся тут на вопросе: Какие счётчики производительности необходимы для того, чтобы быстро понять, являются ли диски «узким местом»?
Рецензенты: Thomas Kejser, Curt Peterson, James Podgorski, Christian Martinez,
Mike Ruthruff
Перевод: Александр Гладченко
Технические редакторы перевода: Алексей Халяко, Ирина Наумова
Функциональность Receive-Side Scaling (RSS) впервые появилась в Windows 2003. Это нововведение было призвано повысить возможности масштабируемости операционной системы Windows, и этим предоставить новые возможности по обслуживанию большого сетевого трафика. Такой трафик характерен для систем, где SQL Server обслуживает OLTP нагрузку. Подробное описание того, какие усовершенствования RSS получила операционная система Windows 2008, можно узнать из отчёта - Receive-Side Scaling Enhancements in Windows Server 2008 и в блоге - Scaling Heavy Network Traffic with Windows.
Ниже представлен свободный перевод одной из глав книги.
Там,
в главе Performance Tuning for Workloads, в разделе, посвящённом оптимизации OLTP - Server under test tunings,
предлагают следующий способ оптимизации
производительности логических дисков (которые предполагает ковыряние реестра,
что, напоминаю, не безопасно и только на ваш страх и риск!):
• Configure
storage devices.
◦ Disable low
priority I/O. For each logical volume in
HKLM\SYSTEM\CurrentControlSet\Enum\SCSI under Device Parameters\ClassPnp,
create a REG_DWROD registry entry named IdlePrioritySupported and set the value
to 0.
SQL Server 2022 — версия продукта: 16.0.4025.1, версия файла: 2022.160.4025.1
Analysis Services — версия продукта: 16.0.43.211, версия файла: 2022.160.43.211
Описание: KB5024396, SQL Server 2022 CU3: How Stella Got Her Groove Back
Скачать: SQLServer2022-KB5024396-x64.exe
SQL Server 2019 — версия продукта: 15.0.4312.2, версия файла: 2019.150.4312.2
Analysis Services — версия продукта: 15.0.35.39, версия файла: 2018.150.35.39
Описание: KB5024276
Скачать: SQLServer2019-KB5024276-x64.exe
Автор: Paul Randal
Опубликовано: 6 января 2015г.
SQL Server 2014 был выпущен еще в апреле прошлого года, и ходили некоторые слухи об изменениях в алгоритме создания VLF. Они направлены на уменьшение числа VLF, когда журнал увеличивается по команде или автоматически (далее я буду говорить для простоты авто-приращение, поскольку это наиболее распространенный сценарий). Я сделал несколько экспериментов и подумал, что понял изменения указанного алгоритма. Оказывается, я понял не всё. На прошлой неделе в переписке MVP всплыл вопрос, который породил целую дискуссию, и мы вместе пришли к выводу, что алгоритм ведет себя недетерминированно… другими словами, мы не знаем, что он делает. Так что я обратился к моим друзьям в CSS, которые исследовали код (спасибо Bob Ward и Suresh Kandoth!) и объяснили изменения.
http://www.mssqltips.com/sqlservertip/3328/sql-server-2014-real-time-query-monitoring/
Проблема
Если вдруг один из запросов к
SQL Server выполняется слишком долго, вы может получить его план исполнения, что даст вам понимание того, что этот
запрос делает, но из этого плана вы не сможете точно определить, что запрос
делает именно в это время, т.е. на каком операторе плана он «застрял»?
Продолжая читать эту статью, вы узнаете, как научится следить за прогрессом
исполнения запроса в режиме реального времени.
Данная статья относится к
следующим версиям SQL Sever: 2008, 2008 R2, 2012 и 2014. Первый вариант статьи
был опубликован в 2011г.
Примечание: в данной статье
под количеством процессоров подразумеваются не сокеты, а представленные в
системе логические процессоры. Рекомендации статьи применимы в тех случаях,
когда для сервера баз данных доступно более восьми логических процессоров.
В зависимости от того, для каких нужд SQL Server использует память, дизайн ядра сервера баз данных предусматривает возможность секционирования распределения памяти. В процессе разработки SQL Server можно было выбирать схему секционирования исполнителя по процессорам, узлам или глобально. Некоторые связанные с распределением памяти функциональные модули SQL Server используют модуль распределения CMemPartitioned. Этот модуль секционирует память по процессорам или NUMA узлам, что может способствовать повышению параллелизма и производительности.
