Abfrageüberlappung
Gilt für:
SQL Server Analysis Services Azure Analysis Services Fabric/Power BI Premium
Die Abfrageinterflechtung ist eine Systemkonfiguration im tabellarischen Modus, die die Abfrageleistung in Szenarien mit hoher Parallelität verbessern kann. Standardmäßig arbeitet die Analysis Services-Tabellarische Engine in Bezug auf die CPU in einer FIFO-Methode (First-In, First-Out). Wenn beispielsweise bei FIFO eine ressourcenintensive und möglicherweise langsame Speicher-Engine-Abfrage empfangen wird, gefolgt von zwei ansonsten schnellen Abfragen, können die schnellen Abfragen möglicherweise blockiert werden, um auf den Abschluss der teuren Abfrage zu warten. Dieses Verhalten wird im folgenden Diagramm dargestellt, das Q1, Q2 und Q3 als die jeweiligen Abfragen, deren Dauer und CPU-Zeit zeigt.
Die Abfrageinterflechtung mit kurzen Abfrageverzerrungen ermöglicht es gleichzeitigen Abfragen, CPU-Ressourcen gemeinsam zu nutzen, was bedeutet, dass schnelle Abfragen nicht hinter langsamen Abfragen blockiert werden. Die Zeit, die zum Abschließen aller drei Abfragen benötigt wird, ist immer noch ungefähr gleich, aber in unserem Beispiel Q2 und Q3 werden nicht bis zum Ende blockiert. Short-Query-Bias bedeutet, dass schnelle Abfragen, die dadurch definiert werden, wie viel CPU jede Abfrage bereits zu einem bestimmten Zeitpunkt verbraucht hat, einen höheren Anteil an Ressourcen zugewiesen werden können als abfragen mit langer Ausführungsdauer. Im folgenden Diagramm gelten Q2- und Q3-Abfragen als schnell und weisen mehr CPU als Q1 auf.
Die Abfrageinterleavierung soll nur geringe oder keine Auswirkungen auf die Leistung von Abfragen haben, die isoliert ausgeführt werden. eine einzelne Abfrage kann immer noch genauso viel CPU verbrauchen wie beim FIFO-Modell.
Wichtige Hinweise
Bevor Sie ermitteln, ob die Abfrageinterleavierung für Ihr Szenario geeignet ist, beachten Sie Folgendes:
- Die Abfrageinterflechtung gilt nur für Importmodelle. Dies wirkt sich nicht auf DirectQuery-Modelle aus.
- Bei der Abfrageinterleaving wird nur die CPU-Auslastung von Abfragen der VertiPaq-Speicher-Engine berücksichtigt. Sie gilt nicht für Formel-Engine-Vorgänge.
- Eine einzelne DAX-Abfrage kann zu mehreren Abfragen der VertiPaq-Speicher-Engine führen. Eine DAX-Abfrage wird basierend auf der CPU-Auslastung ihrer Speichermodulabfragen als schnell oder langsam betrachtet. Die DAX-Abfrage ist die Maßeinheit.
- Aktualisierungsvorgänge sind standardmäßig vor Abfrageinterleaving geschützt. Aktualisierungsvorgänge mit langer Ausführungsdauer werden anders kategorisiert als Abfragen mit langer Ausführungsdauer.
Konfigurieren
Legen Sie zum Konfigurieren der Abfrageinterflechtung die Eigenschaft Threadpool\SchedulingBehavior fest. Diese Eigenschaft kann mit den folgenden Werten angegeben werden:
| Wert | Beschreibung |
|---|---|
| -1 | Automatisch. Die Engine wählt den Warteschlangentyp aus. |
| 0 (Standard für SSAS 2019) | First in, first out (FIFO). |
| 1 | Kurze Abfrageverzerrung. Die Engine drosselt Abfragen mit langer Ausführungszeit schrittweise, wenn sie unter Druck stehen, zugunsten schneller Abfragen. |
| 3 (Standard für Azure AS, Power BI, SSAS 2022 und höher) | Kurze Abfrageverzerrung mit schneller Abbruch. Verbessert die Antwortzeiten von Benutzerabfragen in Szenarien mit hoher Parallelität. Gilt nur für Azure AS, Power BI, SSAS 2022 und höher. |
Derzeit kann die SchedulingBehavior-Eigenschaft nur mithilfe von XMLA festgelegt werden. In SQL Server Management Studio legt der folgende XMLA-Codeausschnitt die SchedulingBehavior-Eigenschaft auf 1 , kurze Abfrageverzerrung, fest.
<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>
Wichtig
Ein Neustart des Instance Servers ist erforderlich. In Azure Analysis Services müssen Sie den Server anhalten und dann fortsetzen und dann effektiv neu starten.
Zusätzliche Eigenschaften
In den meisten Fällen ist SchedulingBehavior die einzige Eigenschaft, die Sie festlegen müssen. Die folgenden zusätzlichen Eigenschaften verfügen über Standardwerte, die in den meisten Szenarien mit kurzen Abfrageverzerrungen funktionieren sollten, können jedoch bei Bedarf geändert werden. Die folgenden Eigenschaften haben keine Auswirkungen, es sei denn, die Abfrageinterflechtung wird durch Festlegen der SchedulingBehavior-Eigenschaft aktiviert.
ReservedComputeForFastQueries : Legt die Anzahl der reservierten logischen Kerne für schnelle Abfragen fest. Alle Abfragen gelten als schnell , bis sie verfallen, da sie eine bestimmte CPU-Menge verbraucht haben. ReservedComputeForFastQueries ist eine ganze Zahl zwischen 0 und 100. Der Standardwert ist 75.
Die Maßeinheit für ReservedComputeForFastQueries ist der Prozentsatz der Kerne. Beispielsweise versucht ein Wert von 80 auf einem Server mit 20 Kernen, 16 Kerne für schnelle Abfragen zu reservieren (während keine Aktualisierungsvorgänge ausgeführt werden). ReservedComputeForFastQueries rundet auf die nächste ganze Anzahl von Kernen auf. Es wird empfohlen, diesen Eigenschaftswert nicht unter 50 festzulegen. Dies liegt daran, dass schnelle Abfragen weggenommen werden können und dem Gesamtentwurf des Features entgegenwirken.
DecayIntervalCPUTime : Eine ganze Zahl, die die CPU-Zeit in Millisekunden darstellt, die eine Abfrage aufwendet, bevor sie abfällt. Wenn das System unter CPU-Druck steht, sind veraltete Abfragen auf die verbleibenden Kerne beschränkt, die nicht für schnelle Abfragen reserviert sind. Der Standardwert ist 60.000. Dies stellt eine Minute CPU-Zeit dar, nicht verstrichene Kalenderzeit.
ReservedComputeForProcessing : Legt die Anzahl der reservierten logischen Kerne für jeden Verarbeitungsvorgang (Datenaktualisierung) fest. Der Eigenschaftswert ist eine ganze Zahl zwischen 0 und 100, wobei der Standardwert 75 ausgedrückt wird. Der Wert stellt einen Prozentsatz der Kerne dar, der von der ReservedComputeForFastQueries-Eigenschaft bestimmt wird. Ein Wert von 0 (null) bedeutet, dass Verarbeitungsvorgänge der gleichen Abfrageinterleavinglogik unterliegen wie Abfragen, sodass sie verfallen können.
Während keine Verarbeitungsvorgänge ausgeführt werden, hat ReservedComputeForProcessing keine Auswirkungen. Beispielsweise reserviert ReservedComputeForFastQueries mit einem Wert von 80 auf einem Server mit 20 Kernen 16 Kerne für schnelle Abfragen. Mit einem Wert von 75 reserviert ReservedComputeForProcessing dann 12 der 16 Kerne für Aktualisierungsvorgänge, sodass 4 für schnelle Abfragen verbleiben, während Verarbeitungsvorgänge ausgeführt werden und CPU verbrauchen. Wie im Abschnitt Verfallene Abfragen unten beschrieben, werden die verbleibenden vier Kerne (nicht für schnelle Abfragen oder Verarbeitungsvorgänge reserviert) weiterhin für schnelle Abfragen und die Verarbeitung im Leerlauf verwendet.
Diese zusätzlichen Eigenschaften befinden sich unter dem Knoten ResourceGovernance-Eigenschaften . In SQL Server Management Studio legt der folgende XMLA-Beispielausschnitt die DecayIntervalCPUTime-Eigenschaft auf einen niedrigeren Wert als den Standardwert fest:
<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>
Veraltete Abfragen
Die in diesem Abschnitt beschriebenen Einschränkungen gelten nur, wenn das System unter CPU-Druck steht. Beispielsweise kann eine einzelne Abfrage, wenn sie die einzige ist, die zu einem bestimmten Zeitpunkt im System ausgeführt wird, alle verfügbaren Kerne nutzen, unabhängig davon, ob sie verfallen ist oder nicht.
Für jede Abfrage sind möglicherweise viele Aufträge für die Speicher-Engine erforderlich. Wenn ein Kern im Pool für veraltete Abfragen verfügbar wird, überprüft der Planer die älteste ausgeführte Abfrage basierend auf der verstrichenen Kalenderzeit, um festzustellen, ob die maximale Kernberechtigung (Maximum Core Entitlement , MCE) bereits verbraucht ist. Wenn nein, wird der nächste Auftrag ausgeführt. Wenn ja, wird die nächstälteste Abfrage ausgewertet. Die Abfrage-MCE wird dadurch bestimmt, wie viele Zerfallsintervalle bereits verwendet wurden. Für jedes verwendete Verfallsintervall wird der MCE basierend auf dem in der folgenden Tabelle gezeigten Algorithmus reduziert. Dies wird fortgesetzt, bis entweder die Abfrage abgeschlossen ist, ein Timeout auftritt oder die MCE auf einen einzelnen Kern reduziert wird.
Im folgenden Beispiel verfügt das System über 32 Kerne, und die CPU des Systems ist unter Druck.
ReservedComputeForFastQueries ist 60 (60 %).
- 20 Kerne (19,2 aufgerundet) sind für schnelle Abfragen reserviert.
- Die restlichen 12 Kerne werden für veraltete Abfragen zugeordnet.
DecayIntervalCPUTime ist 60.000 (1 Minute CPU-Zeit).
Der Lebenszyklus einer Abfrage kann wie folgt aussehen, solange kein Timeout erfolgt oder abgeschlossen ist:
| Phase | Status | Ausführung/Planung | MCE |
|---|---|---|---|
| 0 | Schnell | Die MCE besteht aus 20 Kernen (reserviert für schnelle Abfragen). Die Abfrage wird auf FIFO-Weise in Bezug auf andere schnelle Abfragen in den 20 reservierten Kernen ausgeführt. Das Verfallsintervall von 1 Minute CPU-Zeit wird verbraucht. |
20 = MIN(32/2˄0, 20) |
| 1 | Zerfallen | Die MCE ist auf 12 Kerne festgelegt (12 verbleibende Kerne, die nicht für schnelle Abfragen reserviert sind). Aufträge werden basierend auf der Verfügbarkeit bis mcE ausgeführt. Das Verfallsintervall von 1 Minute CPU-Zeit wird verbraucht. |
12 = MIN(32/2˄1, 12) |
| 2 | Zerfallen | Der MCE ist auf 8 Kerne (Viertel von insgesamt 32 Kernen) festgelegt. Aufträge werden basierend auf der Verfügbarkeit bis mcE ausgeführt. Das Verfallsintervall von 1 Minute CPU-Zeit wird verbraucht. |
8 = MIN(32/2˄2, 12) |
| 3 | Zerfallen | Die MCE ist auf 4 Kerne festgelegt. Aufträge werden basierend auf der Verfügbarkeit bis mcE ausgeführt. Das Verfallsintervall von 1 Minute CPU-Zeit wird verbraucht. |
4 = MIN(32/2˄3, 12) |
| 4 | Zerfallen | Die MCE ist auf 2 Kerne festgelegt. Aufträge werden basierend auf der Verfügbarkeit bis mcE ausgeführt. Das Verfallsintervall von 1 Minute CPU-Zeit wird verbraucht. |
2 = MIN(32/2˄4, 12) |
| 5 | Zerfallen | Die MCE ist auf 1 Kern festgelegt. Aufträge werden basierend auf der Verfügbarkeit bis mcE ausgeführt. Das Verfallsintervall gilt nicht, da die Abfrage den Boden erreicht hat. Kein weiterer Zerfall, da mindestens 1 Kern erreicht ist. |
1 = MIN(32/2˄5, 12) |
Wenn das System unter CPU-Druck steht, werden jeder Abfrage nicht mehr Kerne als der MCE zugewiesen. Wenn alle Kerne derzeit von Abfragen innerhalb ihrer jeweiligen MCEs verwendet werden, warten andere Abfragen, bis Kerne verfügbar werden. Wenn Kerne verfügbar werden, wird die älteste berechtigte Abfrage basierend auf der verstrichenen Kalenderzeit abgerufen. Die MCE ist eine Kappe unter Druck; Es garantiert nicht, dass die Anzahl der Kerne zu einem beliebigen Zeitpunkt vorhanden ist.