Диагностика по устранению неполадок производительности в SQL

Применимо к: База данных SQL Azure

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

Уменьшение времени ожидания при работе с журналами

Каждая база данных и эластичные пулы в Базе данных SQL Azure управляют скоростью создания журналов с помощью регулирования скорости генерации журналов. Ограничение на скорость записи журнала отображается в столбце primary_max_log_rate в sys.dm_user_db_resource_governance.

Иногда скорость генерации логов на основной вычислительной реплике должна быть сокращена для поддержания соглашений об уровне обслуживания. Например, это может произойти, если сервер страницы или другая вычислительная реплика значительно отстает в применении новых записей журнала из службы журналов. Если компоненты гипермасштабирования не отсутствуют, механизм управления скоростью логирования позволяет скорости создания журналов достичь 150 МиБ/с для каждой базы данных на аппаратном обеспечении премиум-серии и оптимизированной для памяти премиум-серии. Для оборудования стандартной серии максимальная скорость журнала составляет 100 МиБ/с для каждой базы данных. Для эластичных пулов максимальная скорость журналов составляет 150 МиБ/с на пул для оборудования серии 'Премиум' и оборудования с оптимизацией памяти, и 125 МиБ/с на пул для другого оборудования.

Следующие типы ожидания отображаются в sys.dm_os_wait_stats при снижении скорости записи в журнал:

Тип ожидания	Причина
`RBIO_RG_STORAGE`	Задержка потребления журналов сервером страницы
`RBIO_RG_DESTAGE`	Задержка потребления данных долгосрочным хранилищем логов
`RBIO_RG_REPLICA`	Задержка потребления журналов вторичной репликой высокой доступности или именованной репликой
`RBIO_RG_GEOREPLICA`	Задержка потребления логов вторичной гео-репликой
`RBIO_RG_DESTAGE`	Задержка обработки журналов службой журналов
`RBIO_RG_LOCALDESTAGE`	Задержка обработки журналов службой журналов
`RBIO_RG_STORAGE_CHECKPOINT`	Задержка в потреблении логов сервером страниц из-за медленной проверки контрольной точки базы данных.
`RBIO_RG_MIGRATION_TARGET`	Задержка потребления журнала базой данных без гипермасштабирования во время обратной миграции

Функция динамического управления (DMF) sys.dm_hs_database_log_rate() предоставляет дополнительные сведения, которые помогут вам понять снижение скорости журнала, если они есть. Например, он может указать, какая конкретная вторичная реплика отстает в применении записей журналов, и каков общий размер журнала транзакций, который еще не применен.

Операции чтения сервера страниц

Реплики вычислений не кэшируют полную копию базы данных локально. Данные, локальные для реплики вычислений, хранятся в буферном пуле (в памяти) и в кэше локального расширения буферного пула (RBPEX), который содержит подмножество наиболее часто доступных страниц данных. Этот локальный кэш SSD имеет размер пропорционально размеру вычислительных ресурсов. С другой стороны, каждый сервер страницы имеет полный кэш SSD для части поддерживаемой базы данных.

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

Несколько динамических управляемых представлений (DMV) и расширенные события имеют столбцы и поля, указывающие число удалений операций чтения с сервера страниц, которое можно сравнить с общим количеством операций чтения. Хранилище запросов также фиксирует считывания сервером страниц в статистике времени выполнения запросов.

Столбцы для отчетов о чтении с сервера страниц доступны в исполняемых динамических представлениях и представлениях каталога.
Поля, которые считываются сервером страниц, присутствуют в следующих расширенных событиях:
- sql_statement_completed
- sp_statement_completed
- sql_batch_completed
- rpc_completed
- scan_stopped
- query_store_begin_persist_runtime_stat
- query_store_execution_runtime_info
ActualPageServerReads / ActualPageServerReadAheads атрибуты присутствуют в XML-коде плана запроса для планов, включающих статистику среды выполнения. Рассмотрим пример.
```
<RunTimeCountersPerThread Thread="8" ActualRows="90466461" [...] ActualPageServerReads="0" ActualPageServerReadAheads="5687297" ActualLobPageServerReads="0" ActualLobPageServerReadAheads="0" />
```
Совет

Чтобы просмотреть эти атрибуты в окне "Свойства плана запроса", требуется SSMS 18.3 или более поздней версии.

Статистика виртуальных файлов и учет операций ввода-вывода

В Azure SQL Database sys.dm_io_virtual_file_stats() DMF — это один из способов мониторинга статистики операций ввода-вывода, таких как IOPS, пропускная способность и задержка. Характеристики ввода-вывода в гипермасштабируемых системах отличаются из-за их распределенной архитектуры . В этом разделе мы сосредоточимся на чтении и записи операций ввода-вывода, как показано в этом DMF.

Для Hyperscale соответствующие данные в sys.dm_io_virtual_file_stats() следующие:

Строки, в database_id которых значение соответствует значению, возвращаемому функцией DB_ID , и где file_id значение отличается от 2, соответствуют серверам страниц. Как правило, каждая строка соответствует одному серверу страницы. Однако для больших файлов используются несколько серверов страниц.
- Строка с file_id 2 соответствует журналу транзакций.
Строки, в которых значение столбца database_id равно 0, соответствуют локальному кэшу SSD на реплике вычислений.

Использование локального кэша SSD

Так как локальный кэш SSD существует на той же вычислительной реплике, где ядро СУБД обрабатывает запросы, операции ввода-вывода для этого кэша быстрее, чем операции ввода-вывода на серверах страниц. В гипермасштабной базе данных или эластичном пуле sys.dm_io_virtual_file_stats() есть специальные строки, сообщающие статистику операций ввода-вывода для локального кэша SSD. Эти строки имеют значение 0 для столбца database_id . Например, следующий запрос возвращает статистику ввода-вывода локального кэша SSD с момента запуска базы данных.

SELECT *
FROM sys.dm_io_virtual_file_stats(0, NULL);

Соотношение агрегированных операций чтения из локальных файлов кэша SSD к агрегированным считываниям из всех остальных файлов данных — это соотношение попаданий локального кэша SSD. Эта метрика предоставляется счетчиками производительности RBPEX cache hit ratio и RBPEX cache hit ratio base, доступными в sys.dm_os_performance_counters DMV.

Считываний данных

При выполнении операций чтения ядром СУБД на реплике вычислений они могут обслуживаться либо локальным кэшем SSD, либо серверами страниц, либо сочетанием двух при чтении нескольких страниц.
Когда реплика вычислений считывает некоторые страницы из определенного файла данных (например, файл с file_id 1), если эти данные находятся исключительно в локальном кэше SSD, все операции ввода-вывода для этого чтения учитываются в файлах локального кэша SSD, где database_id имеет значение 0. Если часть этих данных находится в локальном кэше SSD, а часть находится на серверах страниц, то операции ввода-вывода учитываются частично в отношении файлов локального кэша SSD и частично по отношению к файлам данных, соответствующим серверам страниц.
Когда реплика вычислений запрашивает страницу на определенном LSN с сервера страницы, если сервер страницы еще не достиг запрашиваемого LSN, запрос на реплике вычислений ожидает, пока сервер страницы не догонит до запрашиваемого LSN и не сможет вернуть страницу. Для любого чтения с сервера страницы на реплике вычислений отображается PAGEIOLATCH_* тип ожидания, если он ожидает этого ввода-вывода. В режиме масштабирования это время ожидания включает как время, необходимое для получения запрошенной страницы на сервере страниц, так и номер LSN, а также время, необходимое для перемещения страницы с сервера страниц в реплику вычислений.
Большие операции чтения, такие как предварительное чтение, часто выполняются с помощью чтения с разбросом-сбором. Это позволяет считывать до 4 МБ в виде одной операции ввода-вывода. Однако при чтении данных в локальном кэше SSD эти операции чтения учитываются как несколько отдельных операций чтения 8 КБ, так как буферный пул и локальный кэш SSD всегда используют 8-КБ страниц. В результате число операций чтения, замеченных в локальном кэше SSD, может быть больше фактического количества операций чтения, выполняемых механизмом.

Операции записи данных

Первичная реплика вычислений не записывает непосредственно на серверы страниц. Вместо этого записи журналов из службы журналов воспроизводятся на соответствующих серверах страниц.
Записи в реплике вычислений преимущественно записываются в локальный кэш SSD (database_id 0). Для операций записи, размер которых превышает 8 КБ, то есть выполненных с использованием механизма gather-write, каждая операция записи преобразуется в несколько отдельных записей по 8 КБ в локальный кэш SSD, поскольку буферный пул и локальный кэш SSD всегда используют страницы размером 8 КБ. В результате количество операций ввода-вывода, замеченных в локальном кэше SSD, может быть больше фактического количества операций ввода-вывода, выполняемых подсистемой.
Файлы данных, отличные от database_id 0, которые соответствуют серверам страниц, также могут отображать записи. В Hyperscale эти записи имитируются, так как вычислительные реплики никогда не записывают непосредственно на серверы страниц. Статистика ввода-вывода учитывается по мере их регистрации на вычислительной реплике. Запись операций ввода-вывода в секунду (IOPS), пропускная способность и задержка, наблюдаемые на реплике вычислений для файлов данных, отличных от database_id 0, не отражают фактическую статистику операций ввода-вывода, происходящих на серверах страниц.

Операции записи в журнал

В первичной реплике вычислительных узлов записи журнала учитываются в sys.dm_io_virtual_file_stats() под file_id 2.
В отличие от групп доступности, когда транзакция фиксируется на первичной вычислительной реплике, записи журналов не закреплены на вторичной реплике. В гипермасштабировании журнал закреплен в службе журналов и применяется к вторичным репликам асинхронно. Так как записи журналов на самом деле не происходят на вторичных репликах, учет операций ввода-вывода журнала в sys.dm_io_virtual_file_stats() на вторичных репликах не следует использовать в качестве статистики журнала транзакций.

Ввод-вывод данных в статистику использования ресурсов

В базе данных, не относящейся к гипермасштабируемым, объединенные операции чтения и записи IOPS для файлов данных относительно предела ввода-вывода данных управления ресурсами сообщаются в представлениях sys.dm_db_resource_stats и sys.resource_stats в столбце avg_data_io_percent. Соответствующими динамическими административными представлениями для эластичных пулов являются sys.dm_elastic_pool_resource_stats и sys.elastic_pool_resource_stats. Те же значения отображаются в метриках Azure Monitor как процент операций ввода-вывода данных для баз данных и эластичных пулов.

В гипермасштабируемой базе данных эти столбцы и метрики сообщают об использовании операций ввода-вывода данных относительно ограничений на локальное хранилище SSD только для реплики вычислений, включая операции ввода-вывода в локальном кэше SSD и tempdb базе данных. Значение 100 % в этом столбце указывает, что управление ресурсами ограничивает число операций ввода-вывода в локальном хранилище. Если это связано с проблемой производительности, оптимизируйте рабочую нагрузку, чтобы уменьшить количество операций ввода-вывода, или увеличьте объём вычислительных ресурсов, чтобы увеличить максимальное количество операций ввода-вывода в секунду. Для управления ресурсами локального кэша SSD при операциях чтения и записи система подсчитывает индивидуальные операции ввода-вывода объемом 8 КБ, а не более крупные операции, которые могут инициироваться механизмом базы данных.

Операции ввода-вывода данных на серверы страниц не отображаются в представлениях использования ресурсов или в метриках Azure Monitor, но они сообщаются sys.dm_io_virtual_file_stats(), как упоминалось ранее.

Обратная связь

Была ли эта страница полезна?

Last updated on 2025-11-03