Чередование запросов
Применимо к:
SQL Server Analysis Services Azure Analysis Services Fabric/Power BI Premium
Чередование запросов — это конфигурация системы табличного режима, которая может повысить производительность запросов в сценариях с высоким уровнем параллелизма. По умолчанию табличный модуль служб Analysis Services работает в режиме fifo в отношении ЦП. Например, при использовании FIFO, если получен один ресурсоемкий и, возможно, медленный запрос к подсистеме хранилища, а затем два быстрых запроса в противном случае, быстрые запросы могут быть заблокированы до завершения дорогостоящего запроса. Это поведение показано на следующей схеме, на которой показаны Q1, Q2 и Q3 в качестве соответствующих запросов, их продолжительности и времени ЦП.
Чередование запросов с коротким смещением запросов позволяет параллельным запросам совместно использовать ресурсы ЦП, что означает, что быстрые запросы не блокируются за медленными запросами. Время, необходимое для выполнения всех трех запросов, по-прежнему остается примерно таким же, но в нашем примере кварталы 2 и 3 не блокируются до конца. Смещение коротких запросов означает, что для быстрых запросов, определяемых тем, сколько ресурсов ЦП уже использовал каждый запрос в определенный момент времени, может быть выделена более высокая доля ресурсов, чем для длительных запросов. На следующей схеме запросы Q2 и Q3 считаются быстрыми и выделяют больше ЦП, чем В1.
Чередование запросов предназначено для того, чтобы практически не влиять на производительность запросов, которые выполняются изолированно; Один запрос по-прежнему может потреблять столько ресурсов ЦП, сколько при использовании модели FIFO.
Важные замечания
Прежде чем определить, подходит ли чередование запросов для вашего сценария, помните следующее:
- Чередование запросов применяется только для моделей импорта. Это не влияет на модели DirectQuery.
- При чередовке запросов учитывается только ЦП, потребляемый запросами подсистемы хранилища VertiPaq. Это не относится к операциям подсистемы формул.
- Один запрос DAX может привести к нескольким запросам подсистемы хранилища VertiPaq. Запрос DAX считается быстрым или медленным на основе ресурсов ЦП, потребляемых запросами подсистемы хранилища. Запрос DAX — это единица измерения.
- Операции обновления по умолчанию защищены от чередование запросов. Длительные операции обновления классифицируются иначе, чем длительные запросы.
Configure
Чтобы настроить чередование запросов, задайте свойство Threadpool\SchedulingBehavior . Это свойство можно указать следующими значениями:
| Значение | Описание |
|---|---|
| -1 | Автоматический. Подсистема выберет тип очереди. |
| 0 (по умолчанию для SSAS 2019) | Первый вход, первый выход (FIFO). |
| 1 | Смещение короткого запроса. Подсистема постепенно регулирует длительные запросы под давлением в пользу быстрых запросов. |
| 3 (по умолчанию для Azure AS, Power BI, SSAS 2022 и более поздних версий) | Смещение короткого запроса с быстрой отменой. Сокращает время отклика на запросы пользователей в сценариях с высоким уровнем параллелизма. Применяется только к Azure AS, Power BI, SSAS 2022 и более поздних версий. |
В настоящее время свойство SchedulingBehavior можно задать только с помощью XMLA. В SQL Server Management Studio в следующем фрагменте XMLA для свойства SchedulingBehavior задано значение 1, короткая смещение запроса.
<Alter AllowCreate="true" ObjectExpansion="ObjectProperties" xmlns="http://schemas.microsoft.com/analysisservices/2003/engine">
<Object />
<ObjectDefinition>
<Server xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:ddl2="http://schemas.microsoft.com/analysisservices/2003/engine/2" xmlns:ddl2_2="http://schemas.microsoft.com/analysisservices/2003/engine/2/2" xmlns:ddl100_100="http://schemas.microsoft.com/analysisservices/2008/engine/100/100" xmlns:ddl200="http://schemas.microsoft.com/analysisservices/2010/engine/200" xmlns:ddl200_200="http://schemas.microsoft.com/analysisservices/2010/engine/200/200" xmlns:ddl300="http://schemas.microsoft.com/analysisservices/2011/engine/300" xmlns:ddl300_300="http://schemas.microsoft.com/analysisservices/2011/engine/300/300" xmlns:ddl400="http://schemas.microsoft.com/analysisservices/2012/engine/400" xmlns:ddl400_400="http://schemas.microsoft.com/analysisservices/2012/engine/400/400" xmlns:ddl500="http://schemas.microsoft.com/analysisservices/2013/engine/500" xmlns:ddl500_500="http://schemas.microsoft.com/analysisservices/2013/engine/500/500">
<ID>myserver</ID>
<Name>myserver</Name>
<ServerProperties>
<ServerProperty>
<Name>ThreadPool\SchedulingBehavior</Name>
<Value>1</Value>
</ServerProperty>
</ServerProperties>
</Server>
</ObjectDefinition>
</Alter>
Важно!
Требуется перезапуск экземпляра сервера. В Azure Analysis Services необходимо приостановить, а затем возобновить работу сервера, фактически перезапустив.
Дополнительные свойства
В большинстве случаев единственным свойством, которое необходимо задать, является SchedulingBehavior. Следующие дополнительные свойства имеют значения по умолчанию, которые должны работать в большинстве сценариев с коротким смещением запросов, однако при необходимости их можно изменить. Следующие свойства не действуют , если только не включено чередование запросов, задав свойство SchedulingBehavior.
ReservedComputeForFastQueries — задает количество зарезервированных логических ядер для быстрых запросов. Все запросы считаются быстрыми , пока они не упадут из-за того, что они использовали определенный объем ЦП. ReservedComputeForFastQueries — это целое число от 0 до 100. Значение по умолчанию — 75.
Единицей измерения для ReservedComputeForFastQueries является процент ядер. Например, значение 80 на сервере с 20 ядрами пытается зарезервировать 16 ядер для быстрых запросов (при этом операции обновления не выполняются). ReservedComputeForFastQueries округляет до ближайшего целого числа ядер. Рекомендуется не задавать значение этого свойства ниже 50. Это связано с тем, что быстрые запросы могут быть лишены, и это противоречит общей структуре функции.
DecayIntervalCPUTime — целое число, представляющее время ЦП в миллисекундах, которое запрос тратит до его распада. Если система находится под давлением ЦП, запросы с распадом ограничены оставшимися ядрами, не зарезервированными для быстрых запросов. Значение по умолчанию — 60 000. Это 1 минута времени ЦП, а не затраченное календарное время.
ReservedComputeForProcessing — задает количество зарезервированных логических ядер для каждой операции обработки (обновления данных). Значение свойства представляет собой целое число от 0 до 100 с выраженным значением по умолчанию 75. Значение представляет процент ядер, определенных свойством ReservedComputeForFastQueries. Значение 0 (ноль) означает, что операции обработки подчиняются той же логике чередование запросов, что и запросы, поэтому они могут быть разложены.
Хотя операции обработки не выполняются, ReservedComputeForProcessing не оказывает никакого влияния. Например, при значении 80 ReservedComputeForFastQueries на сервере с 20 ядрами резервирует 16 ядер для быстрых запросов. При значении 75 ReservedComputeForProcessing зарезервирует 12 из 16 ядер для операций обновления, оставив 4 для быстрых запросов, пока выполняются операции обработки и потребляют ЦП. Как описано в разделе "Неактивные запросы " ниже, оставшиеся 4 ядра (не зарезервированные для быстрых запросов или операций обработки) по-прежнему будут использоваться для быстрых запросов и обработки в случае простоя.
Эти дополнительные свойства находятся в узле Свойства ResourceGovernance . В SQL Server Management Studio в следующем примере фрагмента кода XMLA свойство DecayIntervalCPUTime устанавливается ниже значения по умолчанию:
<Alter AllowCreate="true" ObjectExpansion="ObjectProperties" xmlns="http://schemas.microsoft.com/analysisservices/2003/engine">
<Object />
<ObjectDefinition>
<Server xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:ddl2="http://schemas.microsoft.com/analysisservices/2003/engine/2" xmlns:ddl2_2="http://schemas.microsoft.com/analysisservices/2003/engine/2/2" xmlns:ddl100_100="http://schemas.microsoft.com/analysisservices/2008/engine/100/100" xmlns:ddl200="http://schemas.microsoft.com/analysisservices/2010/engine/200" xmlns:ddl200_200="http://schemas.microsoft.com/analysisservices/2010/engine/200/200" xmlns:ddl300="http://schemas.microsoft.com/analysisservices/2011/engine/300" xmlns:ddl300_300="http://schemas.microsoft.com/analysisservices/2011/engine/300/300" xmlns:ddl400="http://schemas.microsoft.com/analysisservices/2012/engine/400" xmlns:ddl400_400="http://schemas.microsoft.com/analysisservices/2012/engine/400/400" xmlns:ddl500="http://schemas.microsoft.com/analysisservices/2013/engine/500" xmlns:ddl500_500="http://schemas.microsoft.com/analysisservices/2013/engine/500/500">
<ID>myserver</ID>
<Name>myserver</Name>
<ServerProperties>
<ServerProperty>
<Name>ResourceGovernance\DecayIntervalCPUTime</Name>
<Value>15000</Value>
</ServerProperty>
</ServerProperties>
</Server>
</ObjectDefinition>
</Alter>
Запросы с затуханием
Ограничения, описанные в этом разделе, применяются только в том случае, если система находится под давлением ЦП. Например, один запрос, если он является единственным, выполняющийся в системе в данный момент времени, может использовать все доступные ядра независимо от того, был ли он распался или нет.
Для каждого запроса может потребоваться множество заданий подсистемы хранилища. Когда ядро в пуле для распакшихся запросов становится доступным, планировщик будет проверка самый старый выполняющийся запрос на основе затраченного календарного времени, чтобы узнать, используется ли уже его максимальное право на использование ядра (MCE). Если нет, выполняется следующее задание. Если да, вычисляется следующий самый старый запрос. McE запроса определяется тем, сколько уже использованных интервалов распада. Для каждого используемого интервала затухания MCE уменьшается на основе алгоритма, показанного в таблице ниже. Это продолжается до тех пор, пока запрос не завершится, не будет истекло время ожидания или mcE не будет сокращено до одного ядра.
В следующем примере система имеет 32 ядра, а ЦП системы находится под давлением.
ReservedComputeForFastQueries — 60 (60 %).
- Для быстрых запросов зарезервировано 20 ядер (19,2 с округлением).
- Оставшиеся 12 ядер выделяются для распакованных запросов.
DecayIntervalCPUTime — 60 000 (1 минута времени ЦП).
Жизненный цикл запроса может быть следующим, если он не истекает или не завершается:
| Этап | Состояние | Выполнение и планирование | MCE |
|---|---|---|---|
| 0 | быстрый; | MCE имеет 20 ядер (зарезервировано для быстрых запросов). Запрос выполняется fifo по отношению к другим быстрым запросам в 20 зарезервированных ядрах. Интервал затухания в 1 минуту времени ЦП используется. |
20 = МИН(32/2˄0, 20) |
| 1 | Распалась | McE имеет значение 12 ядер (12 оставшихся ядер, не зарезервированных для быстрых запросов). Задания выполняются на основе доступности до MCE. Интервал затухания в 1 минуту времени ЦП используется. |
12 = МИН(32/2˄1, 12) |
| 2 | Распалась | Для MCE задано 8 ядер (четверть из 32 ядер). Задания выполняются на основе доступности до MCE. Интервал затухания в 1 минуту времени ЦП используется. |
8 = МИН(32/2˄2, 12) |
| 3 | Распалась | McE имеет значение 4 ядра. Задания выполняются на основе доступности до MCE. Интервал затухания в 1 минуту времени ЦП используется. |
4 = МИН(32/2˄3, 12) |
| 4 | Распалась | Для MCE задано 2 ядра. Задания выполняются на основе доступности до MCE. Интервал затухания в 1 минуту времени ЦП используется. |
2 = МИН(32/2˄4, 12) |
| 5 | Распалась | McE имеет значение 1 ядро. Задания выполняются на основе доступности до MCE. Интервал затухания не применяется, так как запрос имеет нижнее значение. Нет дальнейшего распада, так как достигается минимум 1 ядро. |
1 = MIN(32/2˄5, 12) |
Если система находится под давлением ЦП, каждому запросу будет назначено не больше ядер, чем его MCE. Если все ядра в настоящее время используются запросами в соответствующих mcE, другие запросы ждут, пока ядра станут доступными. По мере того как ядра становятся доступными, выбирается самый старый запрос на основе затраченного календарного времени. MCE является крышкой под давлением; это не гарантирует, что количество ядер в любой момент времени.
См. также раздел
Обратная связь
Ожидается в ближайшее время: в течение 2024 года мы постепенно откажемся от GitHub Issues как механизма обратной связи для контента и заменим его новой системой обратной связи. Дополнительные сведения см. в разделе https://aka.ms/ContentUserFeedback.
Отправить и просмотреть отзыв по