Magas processzorhasználat diagnosztizálása és hibaelhárítása az Azure SQL Database-ben és az SQL Database-ben a Microsoft Fabricben

A következőkre vonatkozik:Azure SQL Database SQL Database a Fabricben

Az Azure SQL Database és a Fabricben található SQL Database beépített eszközöket biztosít a magas processzorhasználat okainak azonosításához és a számítási feladatok teljesítményének optimalizálásához. Ezekkel az eszközökkel elháríthatja a magas processzorhasználatot a probléma fennállása alatt vagy utólag, miután az incidens véget ért. Az automatikus hangolást is engedélyezheti az adatbázis processzorhasználatának proaktív csökkentése érdekében. Ez a cikk bemutatja, hogyan diagnosztizálhatja és háríthatja el a magas processzorhasználatot az Azure SQL Database beépített eszközeivel, és elmagyarázza , hogy mikor kell cpu-erőforrásokat hozzáadnia.

A vCore-szám megértése

Magas CPU-terhelés incidensének diagnosztizálásakor hasznos megérteni, hogy hány virtuális mag (vCore) érhető el az adatbázis számára. A virtuális mag egyenértékű a logikai CPU-val. A virtuális magok száma segít megérteni az adatbázis számára elérhető CPU-erőforrásokat.

Virtuális magok számának azonosítása az Azure Portalon

Az Azure portálon gyorsan megállapíthatja egy adatbázis virtuális magjainak számát, ha virtuális magalapú szolgáltatási szintet használ a kiépített számítási szinttel. Ebben az esetben az adatbázis Áttekintés lapján szereplő tarifacsomag tartalmazza a vCore-ok számát. Egy adatbázis tarifacsomagja például "Általános célú: Standard sorozat (Gen5), 16 virtuális mag".

A kiszolgáló nélküli számítási szinten lévő adatbázisok esetében a virtuális magok száma mindig megegyezik az adatbázis maximális virtuális magbeállításával. Az adatbázis Áttekintés oldalán felsorolt árazási szint tartalmazza a VCore számot. Egy adatbázis tarifacsomagja például "Általános célú: Kiszolgáló nélküli, standard sorozatú (Gen5), 16 virtuális mag".

Ha a DTU alapú vásárlási modellt használja, az adatbázis vCore számának lekérdezéséhez Transact-SQL-t kell használnia.

Virtuális magok számának azonosítása Transact-SQL

A Transact-SQL segítségével azonosíthatja bármely adatbázishoz tartozó aktuális virtuális magok számát. A Transact-SQL lekérdezéseket futtathatja az Azure SQL Database-en az SQL Server Management Studióval (SSMS) vagy az Azure Portal lekérdezésszerkesztőjével.

Csatlakozzon az adatbázishoz, és futtassa a következő lekérdezést:

SELECT 
    COUNT(*) as vCores
FROM sys.dm_os_schedulers
WHERE status = N'VISIBLE ONLINE';
GO

A magas processzorhasználat okainak azonosítása

A processzorkihasználtságot az Azure Portal, a Lekérdezéstár interaktív eszközei az SSMS-ben és Transact-SQL lekérdezések használatával mérheti és elemezheti az SSMS-ben.

Az Azure Portal és a Lekérdezéstár végrehajtási statisztikákat, például CPU-metrikákat jelenít meg a befejezett lekérdezésekhez. Ha egy vagy több folyamatban lévő, hosszú ideig futó lekérdezés által okozott magas cpu-incidenst tapasztal, azonosítsa a jelenleg futó lekérdezéseket a Transact-SQL-lel.

Az új és szokatlan magas processzorhasználat gyakori okai a következők:

Új lekérdezések a számítási feladatban, amelyek nagy mennyiségű CPU-t használnak.
A rendszeresen futó lekérdezések gyakoriságának növekedése.
A lekérdezésterv regressziója, beleértve a paraméterérzékeny tervvel (PSP) kapcsolatos problémák miatti regressziót is, ami egy vagy több lekérdezést eredményez, amely több processzort használ fel.
A lekérdezési tervek fordításának vagy újrafordításának jelentős növekedése.
Adatbázisok, ahol a lekérdezések túlzott párhuzamosságot használnak.

Annak megértéséhez, hogy mi okozza a magas cpu-incidenst, azonosítsa, hogy a magas processzorkihasználtság mikor fordul elő az adatbázison és az akkori processzort használó leggyakoribb lekérdezéseken.

Megvizsgál:

Jelentős processzorhasználatot használó új lekérdezések jelennek meg a számítási feladatban, vagy megnő a rendszeresen futó lekérdezések gyakorisága? A vizsgálathoz használja az alábbi módszerek bármelyikét. Keressen korlátozott előzményű lekérdezéseket (új lekérdezéseket), valamint a hosszabb előzményekkel rendelkező lekérdezések végrehajtási gyakoriságát.
A számítási feladat egyes lekérdezései több processzort használnak végrehajtásonként, mint korábban? Ha igen, megváltozott a lekérdezés végrehajtási terve? Ezek a lekérdezések paraméterérzékeny tervek (PSP) problémáit tartalmazhatják. A vizsgálathoz használja az alábbi technikák valamelyikét. Több lekérdezés-végrehajtási tervvel rendelkező lekérdezéseket keres, és a processzorhasználat jelentős mértékben változik:
- A legutóbbi 15 lekérdezés lekérdezése processzorhasználat alapján a Transact-SQL használatával.
- Interaktív lekérdezéstár-eszközök használata az SSMS-ben a leggyakoribb lekérdezések cpu-idő szerinti azonosításához
Van-e bizonyíték arra, hogy nagy mennyiségű fordítás vagy újrafordítás történik? Lekérdezheti a leggyakrabban lefordított lekérdezéseket a lekérdezés kivonata alapján , és áttekintheti, hogy milyen gyakran fordítják le őket.
A lekérdezések túlzott párhuzamosságot használnak? Lekérdezheti a MAXDOP-adatbázis hatókörű konfigurációját , és áttekintheti a virtuális magok számát. A túlzott párhuzamosság gyakran olyan adatbázisokban fordul elő, ahol a MAXDOP értéke nyolcnál magasabb virtuális magszámmal van beállítva 0 .

Megjegyzés:

Az Azure SQL Database olyan alapvető szolgáltatásfunkciók implementálásához igényel számítási erőforrásokat, mint a magas rendelkezésre állás és vészhelyreállítás, az adatbázis biztonsági mentése és visszaállítása, a monitorozás, a lekérdezéstár, az automatikus hangolás stb. Ezeknek a számítási erőforrásoknak a használata különösen észrevehető lehet az alacsony virtuális magszámú adatbázisokban vagy a sűrű rugalmas készletekben lévő adatbázisokban. További információ az Azure SQL Database erőforrás-kezelésével kapcsolatos tudnivalókról.

Az Azure Portal használatával nyomon követheti a különböző CPU-metrikákat, beleértve az adatbázis által az adott időszakban használt rendelkezésre álló processzor százalékos arányát. Az Azure Portal a CPU-metrikákat az adatbázis Lekérdezéstárából származó információkkal kombinálja, amely lehetővé teszi annak azonosítását, hogy mely lekérdezések használták fel a processzort az adatbázisban egy adott időpontban.

Kövesse az alábbi lépéseket a processzor százalékos metrikáinak megkereséséhez.

Lépjen az adatbázisra az Azure Portalon.
A bal oldali menü Intelligens teljesítmény területén válassza a Lekérdezési teljesítményelemzés lehetőséget.

A Lekérdezési teljesítményelemzés alapértelmezett nézete 24 órányi adatot jelenít meg. A processzorhasználat az adatbázishoz használt teljes rendelkezésre álló processzor százalékos arányaként jelenik meg.

Az ebben az időszakban futó első öt lekérdezés függőleges sávokban jelenik meg a PROCESSZORhasználati grafikon felett. Jelöljön ki egy idősávot a diagramon, vagy használja a Testreszabás menüt adott időszakok feltárásához. Növelheti a megjelenített lekérdezések számát is.

A lekérdezés részleteinek megnyitásához válassza ki az egyes magas processzorhasználatú lekérdezésazonosítót. A részletek közé tartozik a lekérdezés szövege és a lekérdezés teljesítményelőzményei. Vizsgálja meg, hogy a közelmúltban nőtt-e a lekérdezés processzorhasználata.

Jegyezze fel a lekérdezésazonosítót a lekérdezési terv további vizsgálatához a Lekérdezéstár használatával a következő szakaszban.

Az Azure Portalon azonosított leggyakoribb lekérdezések lekérdezési terveinek áttekintése

Az alábbi lépéseket követve lekérdezésazonosítót használhat az SSMS interaktív Lekérdezéstár eszközeiben a lekérdezés végrehajtási tervének időbeli vizsgálatához.

Nyissa meg az SSMS-eket.
Csatlakozzon az Azure SQL Database-hez az Object Explorerben.
Bontsa ki az adatbáziscsomópontot az Object Explorerben.
Bontsa ki a Lekérdezéstár mappát.
Nyissa meg a Követett lekérdezések ablakot.
Írja be a lekérdezés azonosítóját a képernyő bal felső sarkában található Nyomon követés lekérdezésmezőbe , és nyomja le az Enter billentyűt.
Ha szükséges, a Konfigurálás lehetőséget választva állítsa be az időintervallumot a magas processzorkihasználtság idejének megfelelően.

A lapon a lekérdezés végrehajtási tervei és a lekérdezéshez kapcsolódó metrikák láthatók a legutóbbi 24 órában.

A jelenleg futó lekérdezések azonosítása Transact-SQL

Transact-SQL lehetővé teszi a jelenleg futó lekérdezések azonosítását az eddig használt processzoridővel. A Transact-SQL használatával lekérdezheti az adatbázisban a legutóbbi processzorhasználatot, a leggyakoribb lekérdezéseket cpu szerint, valamint a leggyakrabban lefordított lekérdezéseket.

A CPU-metrikákat az SQL Server Management Studióval (SSMS) vagy az Azure Portal lekérdezésszerkesztőjével kérdezheti le. Az SSMS használatakor nyisson meg egy új lekérdezési ablakot, és csatlakoztassa az adatbázishoz (nem az master adatbázishoz).

Az alábbi lekérdezés végrehajtásával megkeresheti az aktuálisan futó lekérdezéseket processzorhasználati és végrehajtási tervekkel. A processzoridő ezredmásodpercben lesz visszaadva.

SELECT
    req.session_id,
    req.status,
    req.start_time,
    req.cpu_time AS 'cpu_time_ms',
    req.logical_reads,
    req.dop,
    s.login_name,
    s.host_name,
    s.program_name,
    object_name(st.objectid,st.dbid) 'ObjectName',
    REPLACE (REPLACE (SUBSTRING (st.text,(req.statement_start_offset/2) + 1,
        ((CASE req.statement_end_offset    WHEN -1    THEN DATALENGTH(st.text) 
        ELSE req.statement_end_offset END - req.statement_start_offset)/2) + 1),
        CHAR(10), ' '), CHAR(13), ' ') AS statement_text,
    qp.query_plan,
    qsx.query_plan as query_plan_with_in_flight_statistics
FROM sys.dm_exec_requests as req  
JOIN sys.dm_exec_sessions as s on req.session_id=s.session_id
CROSS APPLY sys.dm_exec_sql_text(req.sql_handle) as st
OUTER APPLY sys.dm_exec_query_plan(req.plan_handle) as qp
OUTER APPLY sys.dm_exec_query_statistics_xml(req.session_id) as qsx
ORDER BY req.cpu_time desc;
GO

Ez a lekérdezés a végrehajtási terv két példányát adja vissza. Az oszlop query_plan a sys.dm_exec_query_plan végrehajtási tervét tartalmazza. A lekérdezési terv ezen verziója csak a sorok számának becslését tartalmazza, és nem tartalmaz végrehajtási statisztikákat.

Ha az oszlop query_plan_with_in_flight_statistics végrehajtási tervet ad vissza, ez a terv további információt nyújt. Az query_plan_with_in_flight_statistics oszlop a sys.dm_exec_query_statistics_xml adatait adja vissza, amely tartalmazza a "repülés közben" végrehajtási statisztikákat, például a jelenleg futó lekérdezés által eddig visszaadott sorok tényleges számát.

A processzorhasználati metrikák áttekintése az elmúlt órában

Az alábbi lekérdezés sys.dm_db_resource_stats az átlagos processzorhasználatot adja vissza 15 másodperces időközökkel körülbelül az elmúlt órában.

SELECT
    end_time,
    avg_cpu_percent,
    avg_instance_cpu_percent
FROM sys.dm_db_resource_stats
ORDER BY end_time DESC; 
GO

Fontos, hogy ne csak az avg_cpu_percent oszlopra koncentráljon. Az avg_instance_cpu_percent oszlop tartalmazza a felhasználói és a belső számítási feladatok által használt processzort is. Ha avg_instance_cpu_percent közel van a 100%-hoz, a CPU-erőforrások kihasználtak. Ebben az esetben a magas processzorhasználatot kell elhárítania, ha az alkalmazás átviteli sebessége nem elegendő, vagy ha a lekérdezés késése magas.

További információ az Azure SQL Database erőforrás-kezelésével kapcsolatos tudnivalókról.

További lekérdezésekért tekintse át a sys.dm_db_resource_stats példáit.

A legutóbbi 15 lekérdezés lekérdezése processzorhasználat alapján

A Lekérdezéstár nyomon követi a lekérdezések végrehajtási statisztikáit, beleértve a processzorhasználatot is. Az alábbi lekérdezés az elmúlt 2 órában futtatott 15 lekérdezést adja vissza, a processzorhasználat szerint rendezve. A processzoridő ezredmásodpercben lesz visszaadva.

WITH AggregatedCPU AS 
    (SELECT
        q.query_hash, 
        SUM(count_executions * avg_cpu_time / 1000.0) AS total_cpu_ms, 
        SUM(count_executions * avg_cpu_time / 1000.0)/ SUM(count_executions) AS avg_cpu_ms, 
        MAX(rs.max_cpu_time / 1000.00) AS max_cpu_ms, 
        MAX(max_logical_io_reads) max_logical_reads, 
        COUNT(DISTINCT p.plan_id) AS number_of_distinct_plans, 
        COUNT(DISTINCT p.query_id) AS number_of_distinct_query_ids, 
        SUM(CASE WHEN rs.execution_type_desc='Aborted' THEN count_executions ELSE 0 END) AS aborted_execution_count, 
        SUM(CASE WHEN rs.execution_type_desc='Regular' THEN count_executions ELSE 0 END) AS regular_execution_count, 
        SUM(CASE WHEN rs.execution_type_desc='Exception' THEN count_executions ELSE 0 END) AS exception_execution_count, 
        SUM(count_executions) AS total_executions, 
        MIN(qt.query_sql_text) AS sampled_query_text
    FROM sys.query_store_query_text AS qt
    JOIN sys.query_store_query AS q ON qt.query_text_id=q.query_text_id
    JOIN sys.query_store_plan AS p ON q.query_id=p.query_id
    JOIN sys.query_store_runtime_stats AS rs ON rs.plan_id=p.plan_id
    JOIN sys.query_store_runtime_stats_interval AS rsi ON rsi.runtime_stats_interval_id=rs.runtime_stats_interval_id
    WHERE 
            rs.execution_type_desc IN ('Regular', 'Aborted', 'Exception') AND 
        rsi.start_time>=DATEADD(HOUR, -2, GETUTCDATE())
     GROUP BY q.query_hash), 
OrderedCPU AS 
    (SELECT *, 
    ROW_NUMBER() OVER (ORDER BY total_cpu_ms DESC, query_hash ASC) AS RN
    FROM AggregatedCPU)
SELECT *
FROM OrderedCPU AS OD
WHERE OD.RN<=15
ORDER BY total_cpu_ms DESC;
GO

Ez a lekérdezés a lekérdezés kivonatolt értéke alapján csoportosítható. Ha magas értéket talál az number_of_distinct_query_ids oszlopban, vizsgálja meg, hogy egy gyakran futtatott lekérdezés nincs-e megfelelően paraméterezve. Előfordulhat, hogy a nem paraméteres lekérdezések minden végrehajtáskor lefordíthatók, ami jelentős processzorhasználatot és a lekérdezéstár teljesítményét befolyásolja.

Ha többet szeretne tudni az egyes lekérdezésekről, jegyezze fel a lekérdezés kivonatát, és használja az adott lekérdezéskivonat processzorhasználatának és lekérdezési tervének azonosítására.

A leggyakrabban lefordított lekérdezések lekérdezési kivonat alapján történő lekérdezése

A lekérdezési terv összeállítása processzorigényes folyamat. Az Azure SQL Database gyorsítótárcsomagjai a memóriában újra felhasználhatók. Egyes lekérdezések gyakran újrafordításra kerülhetnek, ha nincsenek paraméterezve, vagy ha a RECOMPILE utasítások kényszerítik az újrafordítást.

A Lekérdezéstár nyomon követi a lekérdezések összeállításának számát. Futtassa a következő lekérdezést a Lekérdezéstár 20 legfontosabb lekérdezésének azonosításához a fordítások száma és a fordítások percenkénti átlagos száma alapján:

SELECT TOP (20)
    query_hash,
    MIN(initial_compile_start_time) as initial_compile_start_time,
    MAX(last_compile_start_time) as last_compile_start_time,
    CASE WHEN DATEDIFF(mi,MIN(initial_compile_start_time), MAX(last_compile_start_time)) > 0
        THEN 1.* SUM(count_compiles) / DATEDIFF(mi,MIN(initial_compile_start_time), 
            MAX(last_compile_start_time)) 
        ELSE 0 
        END as avg_compiles_minute,
    SUM(count_compiles) as count_compiles
FROM sys.query_store_query AS q
GROUP BY query_hash
ORDER BY count_compiles DESC;
GO

Egy adott lekérdezéskivonat processzorhasználatának és lekérdezési tervének azonosítása

Futtassa a következő lekérdezést egy adott query_hashlekérdezés egyedi lekérdezésazonosítójának, lekérdezésszövegének és lekérdezés-végrehajtási tervének megkereséséhez. A processzoridő ezredmásodpercben lesz visszaadva.

Cserélje le a @query_hash változó értékét a számítási feladatra érvényes query_hash értékre.

declare @query_hash binary(8);

SET @query_hash = 0x6557BE7936AA2E91;

with query_ids as (
    SELECT
        q.query_hash,
        q.query_id,
        p.query_plan_hash,
        SUM(qrs.count_executions) * AVG(qrs.avg_cpu_time)/1000. as total_cpu_time_ms,
        SUM(qrs.count_executions) AS sum_executions,
        AVG(qrs.avg_cpu_time)/1000. AS avg_cpu_time_ms
    FROM sys.query_store_query q
    JOIN sys.query_store_plan p on q.query_id=p.query_id
    JOIN sys.query_store_runtime_stats qrs on p.plan_id = qrs.plan_id
    WHERE q.query_hash = @query_hash
    GROUP BY q.query_id, q.query_hash, p.query_plan_hash)
SELECT qid.*,
    qt.query_sql_text,
    p.count_compiles,
    TRY_CAST(p.query_plan as XML) as query_plan
FROM query_ids as qid
JOIN sys.query_store_query AS q ON qid.query_id=q.query_id
JOIN sys.query_store_query_text AS qt on q.query_text_id = qt.query_text_id
JOIN sys.query_store_plan AS p ON qid.query_id=p.query_id and qid.query_plan_hash=p.query_plan_hash
ORDER BY total_cpu_time_ms DESC;
GO

Ez a lekérdezés egyetlen sort ad vissza a végrehajtási terv minden variációjára a query_hash lekérdezéstáron belüli teljes történelemre. Az eredmények a teljes CPU-idő alapján vannak rendezve.

Interaktív lekérdezéstár-eszközök használata a korábbi processzorhasználat nyomon követéséhez

Ha inkább grafikus eszközöket szeretne használni, kövesse az alábbi lépéseket az SSMS interaktív Lekérdezéstár eszközeinek használatához.

Nyissa meg az SSMS-t, és csatlakozzon az adatbázishoz az Object Explorerben.
Az adatbáziscsomópont kibontása az Object Explorerben
Bontsa ki a Lekérdezéstár mappát.
Nyissa meg a Teljes erőforrás-felhasználás panelt.

Az adatbázis teljes processzorideje ezredmásodpercben jelenik meg a panel bal alsó részén. Az alapértelmezett nézetben a processzoridő naponta összesítve lesz.

A panel jobb felső sarkában válassza a Konfigurálás lehetőséget egy másik időszak kiválasztásához. Az aggregáció egységét is módosíthatja. Dönthet például úgy, hogy egy adott dátumtartomány adatait látja, és óránként összesíti az adatokat.

Interaktív lekérdezéstár-eszközök használata a leggyakoribb lekérdezések cpu-idő szerinti azonosításához

Jelöljön ki egy sávot a diagramon a részletezéshez, és tekintse meg az adott időszakban futó lekérdezéseket. Ekkor megnyílik a Leggyakoribb erőforrás-fogyasztó lekérdezések panel. Másik lehetőségként megnyithatja a leggyakoribb erőforrás-fogyasztó lekérdezéseket az adatbázis lekérdezéstár csomópontjáról közvetlenül az Object Explorerben.

Az alapértelmezett nézetben a Leggyakoribb erőforrás-fogyasztó lekérdezések panel időtartam (ms) szerint jeleníti meg a lekérdezéseket. Az időtartam néha alacsonyabb lehet, mint a processzoridő: a párhuzamosságot használó lekérdezések sokkal több processzoridőt használnak, mint a teljes időtartamuk. Ha a várakozási idő jelentős, az időtartam is magasabb lehet a processzoridőnél. A lekérdezések cpu-idő szerinti megtekintéséhez válassza a panel bal felső részén található Metrika legördülő listát, és válassza a CPU-idő(ms) lehetőséget.

A bal felső negyed minden sávja egy lekérdezést jelöl. Jelöljön ki egy sávot a lekérdezés részleteinek megtekintéséhez. A képernyő jobb felső negyedében látható, hogy hány végrehajtási terv található a Lekérdezéstárban a lekérdezéshez, és leképezi őket a végrehajtásuk időpontja és a kiválasztott metrika kihasználtsága alapján. Az egyes tervazonosítók kiválasztásával szabályozhatja, hogy melyik lekérdezés-végrehajtási terv jelenjen meg a képernyő alsó felében.

Megjegyzés:

A Lekérdezéstár nézetei és a Legnagyobb erőforrás-felhasználók nézetben megjelenő alakzatok értelmezéséhez szükséges útmutató megtekintéséhez lásd a lekérdezéstárral kapcsolatos ajánlott eljárásokat.

A processzorhasználat csökkentése

A hibaelhárítás része lehet az előző szakaszban azonosított lekérdezések további megismerése. Csökkentheti a processzorhasználatot az indexek finomhangolásával, az alkalmazásminták módosításával, a lekérdezések finomhangolásával és az adatbázis processzorhasználati beállításainak módosításával.

Ha a számítási feladatban jelentős processzorhasználatot használó új lekérdezéseket talált, ellenőrizze, hogy az indexek optimalizálva lettek-e ezekhez a lekérdezésekhez. Az indexeket manuálisan hangolhatja , vagy csökkentheti a processzorhasználatot az automatikus indexhangolással. Értékelje ki, hogy a maximális párhuzamossági fok megfelelő-e a megnövekedett számítási feladathoz.
Ha úgy találta, hogy a lekérdezések teljes végrehajtási száma magasabb, mint korábban volt, hangolja az indexeket a legmagasabb processzorhasználatú lekérdezésekhez , és fontolja meg az automatikus indexhangolást. Értékelje ki, hogy a maximális párhuzamossági fok megfelelő-e a megnövekedett számítási feladathoz.
Ha a számítási feladatban paraméterérzékeny tervvel (PSP) kapcsolatos lekérdezéseket talált, fontolja meg az automatikus tervkorrekciót (kényszerterv). Manuálisan is érvényesíthet egy tervet a Lekérdezéstárban, vagy finomhangolhatja a lekérdezés Transact-SQL, hogy következetesen nagy teljesítményű lekérdezéstervet eredményezzen.
Ha bizonyítékot talált arra, hogy nagy mennyiségű fordítás vagy újrafordítás történik, hangolja a lekérdezéseket úgy, hogy azok megfelelően paraméterezhetők legyenek, vagy ne igényelhessenek újrafordítási tippeket.
Ha azt találta, hogy a lekérdezések túlzott párhuzamosságot használnak, állítsa be a párhuzamosság maximális fokát.

Tekintse át az alábbi stratégiákat ebben a szakaszban.

Processzorhasználat csökkentése automatikus indexhangolással

Az index hatékony finomhangolása számos lekérdezés processzorhasználatát csökkenti. Az optimalizált indexek csökkentik a lekérdezések logikai és fizikai olvasását, ami gyakran azt eredményezi, hogy a lekérdezésnek kevesebb munkát kell végeznie.

Az Azure SQL Database automatikus indexkezelést biztosít az elsődleges replikák számítási feladataihoz. Az automatikus indexkezelés gépi tanulással figyeli a teljesítményterhelést, és optimalizálja a sororientált lemezalapú nem klaszterezett indexeket az adatbázis számára.

Tekintse át a teljesítményjavaslatokat, beleértve az indexjavaslatokat is az Azure Portalon. Ezeket a javaslatokat manuálisan is alkalmazhatja, vagy engedélyezheti az INDEX LÉTREHOZÁSA automatikus finomhangolási lehetőséget az új indexek adatbázisbeli teljesítményének létrehozásához és ellenőrzéséhez.

Cpu-használat csökkentése automatikus tervkorrekcióval (kényszerterv)

A magas CPU-incidensek másik gyakori oka a végrehajtási terv választási regressziója. Az Azure SQL Database automatikus hangolási lehetőséget kínál a kényszerítési terv automatikus finomhangolási beállításához, amellyel azonosíthatja a lekérdezés-végrehajtási tervek regresszióit az elsődleges replikák számítási feladataiban. Ha engedélyezve van ez az automatikus hangolási funkció, az Azure SQL Database ellenőrzi, hogy a lekérdezés-végrehajtási terv kényszerítése megbízhatóbb teljesítményt eredményez-e a végrehajtási terv regressziójával rendelkező lekérdezések esetében.

Ha az adatbázis 2020 márciusa után lett létrehozva, a kényszerterv automatikus hangolási lehetősége automatikusan engedélyezve lett. Ha az adatbázist ezt megelőzően hozták létre, érdemes engedélyezni a kényszerterv automatikus hangolási opcióját.

Indexek manuális finomhangolása

A magas processzorhasználat okainak azonosítása című részben ismertetett módszerek segítségével azonosítsa a legnagyobb processzorhasználatú lekérdezések lekérdezési terveit. Ezek a végrehajtási tervek segítséget nyújtanak a nem klaszterezett indexek azonosításában és hozzáadásában a lekérdezések felgyorsítása érdekében.

Az adatbázis minden lemezalapú nemclustered indexéhez tárhelyre van szükség, és az SQL-motornak kell azokat fenntartania. Ha lehetséges, módosítsa a meglévő indexeket új indexek hozzáadása helyett, és győződjön meg arról, hogy az új indexek sikeresen csökkentik a processzorhasználatot. A nem klaszterezett indexek áttekintéséhez tekintse meg a Nemclustered Index Design Guidelines című útmutatót.

Egyes számítási feladatok esetében az oszlopcentrikus indexek a legjobb választás a gyakori olvasási lekérdezések processzorhasználatának csökkentésére. Lásd : Oszlopcentrikus indexek – Tervezési útmutató magas szintű javaslatokhoz olyan forgatókönyvekhez, amikor az oszlopcentrikus indexek megfelelőek lehetnek.

Az alkalmazás, a lekérdezések és az adatbázis beállításainak finomhangolása

A leggyakoribb lekérdezések vizsgálatakor olyan alkalmazás-antipatterneket talál, mint a "csevegés" viselkedése, a horizontális skálázás előnyeit élvező számítási feladatok és az optimálisnál rosszabb adatbázis-hozzáférés kialakítása. Az olvasásigényes feladatok esetében fontolja meg az írásvédett replikák használatát az írásvédett lekérdezési munkaterhelés kiszolgálására, valamint az alkalmazásszintű gyorsítótárazást mint hosszú távú stratégiákat a gyakran lekérdezett adatok felskálázására.

Dönthet úgy is, hogy manuálisan finomhangolja a felső processzort a számítási feladatban azonosított lekérdezések használatával. A manuális hangolási lehetőségek közé tartozik a Transact-SQL utasítások újraírása, a tervek kényszerítése a Lekérdezéstárban, valamint a lekérdezési javaslatok alkalmazása.

Ha azonosít olyan eseteket, amikor a lekérdezések néha nem optimális végrehajtási tervet használnak a teljesítmény szempontjából, tekintse át a paraméterérzékeny terv (PSP) problémáit okozó lekérdezések megoldásait.

Ha nagy számú tervvel azonosít nem paraméteres lekérdezéseket, fontolja meg ezeknek a lekérdezéseknek a paraméterezését, ügyelve arra, hogy a paraméter adattípusait teljes mértékben deklarálja, beleértve a hosszt és a pontosságot is. Ez történhet a lekérdezések módosításával, egy terv útmutatójának létrehozásával egy adott lekérdezés paraméterezésének kényszerítéséhez , vagy az adatbázis szintjén a kényszerített paraméterezés engedélyezésével.

Ha magas fordítási arányú lekérdezéseket azonosít, azonosítsa, mi okozza a gyakori fordítást. A gyakori fordítás leggyakoribb oka a RECOMPILE utasítások. Amikor csak lehetséges, állapítsa meg, hogy mikor lett hozzáadva a RECOMPILE tipp, és hogy milyen problémát kellett megoldania. Vizsgálja meg, hogy implementálható-e egy alternatív teljesítményhangolási megoldás a gyakran futó lekérdezések számára, amely biztosítja a konzisztens teljesítményt RECOMPILE tipp nélkül.

A processzorhasználat csökkentése a párhuzamosság maximális fokának finomhangolásával

A max. párhuzamossági fok (MAXDOP) beállítás szabályozza a lekérdezések közötti párhuzamosságot az adatbázismotorban. A magasabb MAXDOP értékek általában több párhuzamos szálat eredményeznek lekérdezésenként, és gyorsabban hajtják végre a lekérdezéseket.

Bizonyos esetekben az egyidejűleg futó nagyszámú párhuzamos lekérdezés lelassíthatja a számítási feladatokat, és magas processzorhasználatot okozhat. A túlzott párhuzamosság valószínűleg nagy számú virtuális maggal rendelkező adatbázisokban fordul elő, ahol a MAXDOP nagy számra vagy nullára van beállítva. Ha a MAXDOP értéke nulla, az adatbázismotor a párhuzamos szálak által használandó ütemezők számát a logikai magok teljes számára vagy 64-re állítja, attól függően, hogy melyik kisebb.

Az adatbázis párhuzamossági beállításának maximális fokát a Transact-SQL használatával azonosíthatja. Csatlakozzon az adatbázishoz az SSMS használatával, és futtassa a következő lekérdezést:

SELECT 
    name, 
    value, 
    value_for_secondary, 
    is_value_default 
FROM sys.database_scoped_configurations
WHERE name=N'MAXDOP';
GO

Fontolja meg a MAXDOP-konfiguráció adatbázisszinten végzett kis módosításokkal való kísérletezését, vagy az egyes problémás lekérdezések módosítását, hogy egy nem hibás MAXDOP-t használjon egy lekérdezési tipp használatával. További információkért tekintse meg a párhuzamosság maximális fokának konfigurálására vonatkozó példákat.

Mikor kell cpu-erőforrásokat hozzáadni?

Előfordulhat, hogy a számítási feladat lekérdezései és indexei megfelelően vannak hangolva, vagy hogy a teljesítmény finomhangolása olyan módosításokat igényel, amelyeket belső folyamatok vagy egyéb okok miatt rövid távon nem tud végrehajtani. További CPU-erőforrások hozzáadása hasznos lehet ezekhez az adatbázisokhoz. Az adatbázis-erőforrásokat minimális állásidővel skálázhatja.

További CPU-erőforrásokat adhat hozzá az Azure SQL Database-hez a virtuális magok számának vagy az adatbázisok hardverkonfigurációjának konfigurálásával a virtuálismag-vásárlási modell használatával.

A DTU-alapú vásárlási modell áttekintése alatt emelheti a szolgáltatási szintet, és növelheti az adatbázis-tranzakciós egységek (DTU-k) számát. A DTU a processzor, a memória, az olvasás és az írás vegyes mértéke. A virtuális mag vásárlási modell egyik előnye, hogy részletesebb vezérlést tesz lehetővé a használt hardver és a virtuális magok száma felett. Migrálhatja az Azure SQL Database-t a DTU-alapú modellből a mag alapú modellbe a vásárlási modellek közötti váltáshoz.

Visszajelzés

Hasznosnak találta ezt az oldalt?

Last updated on 2025-11-20