Lekérdezések összekapcsolása

A következőkre vonatkozik: SQL Server Analysis Services Azure Analysis Services Fabric/Power BI Premium

A lekérdezések közötti összekapcsolás táblázatos módú rendszerkonfiguráció, amely javíthatja a lekérdezési teljesítményt nagy egyidejűségi forgatókönyvekben. Alapértelmezés szerint az Analysis Services táblázatos motorja első be, első ki (FIFO) módon működik a processzor vonatkozásában. A FIFO esetében például, ha egy erőforrás költséges és esetleg lassú tárolómotoros lekérdezés érkezik, majd két, egyébként gyors lekérdezés következik, a gyors lekérdezések blokkolva lehetnek a költséges lekérdezés befejezésére várva. Ez a viselkedés az alábbi ábrán látható, amely az 1., a 2. és a 3. negyedévet jeleníti meg a megfelelő lekérdezésekként, azok időtartamát és cpu-idejét.

A lekérdezések rövid lekérdezési torzításokkal való összekapcsolása lehetővé teszi az egyidejű lekérdezések számára a CPU-erőforrások megosztását, ami azt jelenti, hogy a gyors lekérdezések nem blokkolódnak lassú lekérdezések mögött. A három lekérdezés végrehajtásához szükséges idő még mindig nagyjából azonos, de a mi példánkban a 2. és a 3. negyedév nem lesz letiltva a végéig. A rövid lekérdezés előnyben részesítése gyors lekérdezéseket jelent, amelyek során meghatározza, mennyi CPU-t használt már fel az egyes lekérdezések egy adott időpontban, és ezek az erőforrások nagyobb hányadát kaphatják, mint a hosszú futásidejű lekérdezések. Az alábbi ábrán a Q2 és a Q3 lekérdezések gyorsnak minősülnek, és az 1. negyedévnél több processzort foglalnak le.

A lekérdezések váltogatásának az a célja, hogy az elszigetelten futó lekérdezések teljesítményére kevés vagy egyáltalán semmilyen hatása ne legyen; egyetlen lekérdezés továbbra is annyi CPU-t képes igénybe venni, mint a FIFO-modell esetében.

Fontos tényezők

Mielőtt eldöntené, hogy a lekérdezések közötti kapcsolat megfelelő-e a forgatókönyvhöz, tartsa szem előtt az alábbiakat:

• A lekérdezések közötti váltás csak az import modellekre vonatkozik. Ez nem érinti a DirectQuery-modelleket.
• A kérés-összeillesztés csak a VertiPaq tárolómotor-lekérdezések által felhasznált CPU-t veszi figyelembe. Ez nem vonatkozik a képletmotor műveleteire.
• Egyetlen DAX-lekérdezés több VertiPaq-tárolómotor-lekérdezést eredményezhet. A DAX-lekérdezések gyorsnak vagy lassúnak tekinthetők a tárolómotor lekérdezései által felhasznált PROCESSZOR alapján. A DAX-lekérdezés a mértékegység.
• A frissítési műveletek alapértelmezés szerint védettek a lekérdezések közötti műveletektől. A hosszú ideig futó frissítési műveletek másként vannak kategorizálva, mint a hosszú ideig futó lekérdezések.

Konfigurálás

A lekérdezések köztes futtatásának konfigurálásához állítsa be a Threadpool\SchedulingBehavior tulajdonságot. Ez a tulajdonság a következő értékekkel adható meg:

Érték	Description
-1	Automatikus. Az algoritmus kiválasztja az üzenetsor típusát.
0 (az SSAS 2019 alapértelmezett beállítása)	Először be, először ki (FIFO).
1	Rövid lekérdezési torzítás. A motor fokozatosan korlátozza a hosszú ideig futó lekérdezéseket, amikor nyomás alatt áll, a gyors lekérdezések érdekében.
3 (az Azure AS, a Power BI, az SSAS 2022 és újabb verziók alapértelmezett beállítása)	Rövid lekérdezési eltolódás gyors törléssel. Javítja a felhasználói lekérdezések válaszidejének idejét a magas egyidejűségi forgatókönyvekben. Csak az Azure AS, a Power BI, az SSAS 2022 és újabb verziókra vonatkozik.

Az SchedulingBehavior tulajdonság jelenleg csak XMLA használatával állítható be. Az SQL Server Management Studióban az alábbi XMLA-kódrészlet az SchedulingBehavior tulajdonságot 1, rövid lekérdezési torzításra állítja.

<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>

Fontos

Újra kell indítani a kiszolgálópéldányt. Az Azure Analysis Servicesben szüneteltetnie kell a kiszolgálót, majd újra kell indítania, ezzel gyakorlatilag újraindítja azt.

További tulajdonságok

A legtöbb esetben az SchedulingBehavior az egyetlen beállításra szoruló tulajdonság. Az alábbi további tulajdonságok alapértelmezett értékekkel rendelkeznek, amelyek a legtöbb esetben rövid lekérdezési torzítással működnek, de szükség esetén módosíthatók. Az alábbi tulajdonságok nincs hatásuk, hacsak a lekérdezési átfedés nincs engedélyezve a SchedulingBehavior tulajdonság beállításával.

ReservedComputeForFastQueries – A fenntartott logikai magok számát állítja be a gyors lekérdezésekhez. Minden lekérdezés gyorsnak minősül, amíg el nem romlik, mert felhasználtak egy bizonyos mennyiségű CPU-t. A ReservedComputeForFastQueries egy 0 és 100 közötti egész szám. Az alapértelmezett érték 75.

A ReservedComputeForFastQueries mértékegysége a magok százalékos aránya. Egy 20 magos kiszolgálón például egy 80-at tartalmazó érték 16 magot próbál lefoglalni a gyors lekérdezésekhez (miközben nem végez frissítési műveleteket). A ReservedComputeForFastQueries a legközelebbi teljes magszámra kerekít. Javasoljuk, hogy ezt a tulajdonságértéket ne állítsa 50 alá. Ennek az az oka, hogy a gyors lekérdezéseket meg lehet fosztani, és ellentétes a funkció általános kialakításával.

DecayIntervalCPUTime – Ezredmásodpercben a processzoridőt jelképező egész szám, amelyet a lekérdezés a lebomlása előtt tölt. Ha a rendszer processzorterhelés alatt áll, a lebomló lekérdezések a gyors lekérdezésekhez nem fenntartott fennmaradó magokra korlátozódnak. Az alapértelmezett érték 60 000. Ez 1 perc processzoridőt jelent, nem pedig eltelt naptári időt.

ReservedComputeForProcessing – Beállítja a fenntartott logikai magok számát az egyes feldolgozási (adatfrissítési) műveletekhez. A tulajdonság értéke egy 0 és 100 közötti egész szám, amelynek alapértelmezett értéke 75. Az érték a ReservedComputeForFastQueries tulajdonság által meghatározott magok százalékos arányát jelöli. A 0 (nulla) érték azt jelenti, hogy a feldolgozási műveletekre ugyanaz a lekérdezések közötti logika vonatkozik, mint a lekérdezésekre, így azok lebonthatók.

Amíg nincs feldolgozási művelet, a ReservedComputeForProcessing nincs hatással. Például a 80-at tartalmazó ReservedComputeForFastQueries egy 20 magos kiszolgálón 16 magot foglal le a gyors lekérdezésekhez. A 75-ös értékkel a ReservedComputeForProcessing ezután a 16 magból 12-t lefoglal a frissítési műveletekhez, 4-et pedig a gyors lekérdezésekhez, miközben a feldolgozási műveletek futnak és processzort használnak. Az alábbi , a pusztult lekérdezésekről szóló szakaszban leírtak szerint a fennmaradó 4 mag (nem a gyors lekérdezésekhez vagy a feldolgozási műveletekhez van fenntartva) továbbra is a gyors lekérdezésekhez és a feldolgozáshoz lesznek használva, ha üresjáratban vannak.

Ezek a további tulajdonságok a ResourceGovernance tulajdonságcsomópont alatt találhatók. Az SQL Server Management Studióban az alábbi XMLA-kódrészlet az alapértelmezettnél alacsonyabb értékre állítja a DecayIntervalCPUTime tulajdonságot:

<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>

Elavult lekérdezések

Az ebben a szakaszban ismertetett korlátozások csak akkor érvényesek, ha a rendszer processzorterhelés alatt áll. Ha például egyetlen lekérdezés fut a rendszerben egy adott időpontban, akkor az összes elérhető magot felhasználhatja, függetlenül attól, hogy az elromlott-e vagy sem.

Minden lekérdezéshez számos tárolómotoros feladat szükséges. Ha a poolban elérhetővé válik egy mag a leromlott lekérdezésekhez, az ütemező az eltelt naptári idő szerint megvizsgálja a legrégebben futó lekérdezést, hogy felhasználta-e már a Maximális Mag Jogosultságát (MCE). Ha nem, a rendszer végrehajtja a következő feladatot. Ha igen, a következő legrégebbi lekérdezés lesz kiértékelve. Az MCE lekérdezést az határozza meg, hogy hány bomlási időközt használt már. Minden használt bomlási időköz esetében az MCE az alábbi táblázatban látható algoritmus alapján csökken. Ez mindaddig folytatódik, amíg a lekérdezés befejeződik, túllépi az időkorlátot, vagy az MCE egyetlen magra csökken.

Az alábbi példában a rendszer 32 maggal rendelkezik, és a rendszer processzora nyomás alatt áll.

A "ReservedComputeForFastQueries" értéke 60 (60%).

• A gyors lekérdezésekhez 20 mag van fenntartva (19,2-re felfelé kerekítve).
• A fennmaradó 12 mag le van osztva a kifutó lekérdezésekhez.

A DecayIntervalCPUTime értéke 60 000 (1 perc processzoridő).

A lekérdezés életciklusa a következő lehet, amennyiben nem lép időtúllépésbe vagy nem fejeződik be:

Színpad	Státusz	Végrehajtás/ütemezés	MCE
0	Gyors	Az MCE 20 mag (a gyors lekérdezésekhez van fenntartva). A lekérdezés FIFO-módon történik, a 20 fenntartott processzormagon belüli egyéb gyors lekérdezések vonatkozásában. Az 1 perces CPU időtartam lejárt.	20 = MIN(32/2˄0, 20)
1	Korhadt	Az MCE 12 magra van állítva (ezek a magok nincsenek fenntartva gyors lekérdezésekhez). A feladatok végrehajtása az MCE-ig elérhető elérhetőség alapján történik. A 1 perces CPU időintervallum kimerült.	12 = MIN(32/2˄1, 12)
2	Korhadt	Az MCE 8 magra van beállítva (32 teljes mag negyede). A feladatok végrehajtása az MCE-ig elérhető elérhetőség alapján történik. Az 1 perces processzoridő-lejárat került felhasználásra.	8 = MIN(32/2˄2, 12)
3	Korhadt	Az MCE négy magra van beállítva. A feladatok végrehajtása az MCE-ig elérhető elérhetőség alapján történik. A rendszer bontási intervalluma 1 percnyi processzoridőt használ fel.	4 = MIN(32/2^3, 12)
4	Korhadt	Az MCE 2 magra van állítva. A feladatok végrehajtása az MCE-ig elérhető elérhetőség alapján történik. A rendszer bontási intervalluma 1 percnyi processzoridőt használ fel.	2 = MIN(32/2˄4, 12)
5	Korhadt	Az MCE 1 magra van állítva. A feladatok végrehajtása az MCE-ig elérhető elérhetőség alapján történik. A bomlási időköz nem érvényes, mivel a lekérdezés alulra süllyedt. Nincs további bomlás, miután elérte a minimum 1 magot.	1 = MIN(32/2˄5, 12)

Ha a rendszer processzorterhelés alatt áll, egyetlen lekérdezéshez sem lesz több mag hozzárendelve, mint amennyi az MCE-je. Ha az összes magot jelenleg a saját MCE-jükben lévő lekérdezések használják, akkor a többi lekérdezés megvárja, amíg a magok elérhetővé válnak. Amint a magok elérhetővé válnak, az eltelt naptári idő alapján a legrégebbi jogosult lekérdezés kerül kiválasztásra. Az MCE nyomás alatt álló korlát; nem garantálja, hogy bármely időpontban állandó számú mag lesz elérhető.

Lásd még

Kiszolgálótulajdonságok az Analysis Servicesben