Megosztás a következőn keresztül:

Magas processzorhasználat diagnosztizálása és hibaelhárítása az Azure SQL Database esetében

  • Cikk

A következőre vonatkozik: Azure SQL Database

Az Azure 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, amíg az bekövetkezik, vagy az incidens befejeződése után újra aktívan. 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 virtuális magok számának ismertetése

A magas CPU-incidens diagnosztizálásakor hasznos megérteni az adatbázis számára elérhető virtuális magok (virtuális magok) számát. 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 Portalon gyorsan azonosí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ési oldalán szereplő tarifacsomag tartalmazza a virtuális magok 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. A virtuális magok száma megjelenik az adatbázis áttekintési oldalán felsorolt tarifacsomagban. 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 modell alatt használ adatbázist, a Transact-SQL használatával le kell kérdeznie az adatbázis virtuális magjainak számát.

Virtuális magok számának azonosítása a Transact-SQL használatával

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

Csatlakozás az adatbázisba, é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 processzorhasználatot az Azure Portal, a Lekérdezéstár interaktív eszközei az SSMS-ben és a Transact-SQL-lekérdezések segítségével mérheti és elemezheti az SSMS-ben és az Azure Data Studióban.

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.
  • Jelentősen megnövekedett a lekérdezéstervek fordításának vagy újrafordításának mennyisége.
  • 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.

Vizsgálja meg:

Feljegyzé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.

  1. Lépjen az adatbázisra az Azure Portalon.
  2. 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.

Screenshot shows Query Performance Insight in the Azure portal.

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.

  1. Nyissa meg az SSMS-t.
  2. Csatlakozás az Azure SQL Database-hez az Object Explorerben.
  3. Bontsa ki az adatbáziscsomópontot az Object Explorerben.
  4. Bontsa ki a Lekérdezéstár mappát.
  5. Nyissa meg a Korrektúrák panelt.
  6. Í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.
  7. 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 megjelennek a végrehajtási terv(ek) és a lekérdezéshez kapcsolódó metrikák a legutóbbi 24 órában.

Az aktuálisan futó lekérdezések azonosítása a Transact-SQL-lel

A 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ázis legutóbbi processzorhasználatát, a leggyakoribb cpu-lekérdezéseket és a leggyakrabban lefordított lekérdezéseket.

A CPU-metrikákat az SQL Server Management Studióval (SSMS), az Azure Data Studióval vagy az Azure Portal lekérdezésszerkesztőjével kérdezheti le. Az SSMS vagy az Azure Data Studio 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 100%, a CPU-erőforrások telítettek. 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 fordíthatók le, ha nincsenek paraméterezve, vagy ha a RECOMPILE-tippek kényszerítik az újrafordítást.

A Lekérdezéstár nyomon követi a lekérdezések fordí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

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.

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 egy sort ad vissza a végrehajtási terv minden változatához a query_hash lekérdezéstár teljes előzményeihez. 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.

  1. Nyissa meg az SSMS-t, és csatlakozzon az adatbázishoz az Object Explorerben.
  2. Az adatbáziscsomópont kibontása az Object Explorerben
  3. Bontsa ki a Lekérdezéstár mappát.
  4. 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.

Screenshot shows the Overall Resource Consumption view of Query Store in SSMS.

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.

Screenshot shows the Top Resource Consuming Queries pane for Query Store in S S M S.

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ő menü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.

Feljegyzés

A Lekérdezéstár nézeteinek és a felső erőforrás-fogyasztók nézetében megjelenő alakzatoknak a lekérdezéstárral kapcsolatos ajánlott eljárások című témakörében talál útmutatást

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.

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 számítási feladatokat, és optimalizálja a sorkataszteres lemezalapú nemclustered indexeket az adatbázishoz.

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 tesztelni fogja, 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ázis korábban lett létrehozva, érdemes lehet engedélyezni a kényszerterv automatikus finomhangolási beállítását.

Indexek manuális finomhangolása

A magas processzorhasználat okainak azonosításához használja a magas processzorhasználat okainak azonosítására szolgáló módszereket a legfelső processzorhasználatú lekérdezések lekérdezési terveinek azonosításához. Ezek a végrehajtási tervek segítséget nyújtnak a nemclustered 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, amelyet az SQL-motornak kell 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 nemclustered indexek áttekintését lásd : Nemclustered Index Design Guidelines.

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 írásvédett számítási feladatok esetében fontolja meg az írásvédett replikák kiszervezését az írásvédett lekérdezési számítási feladatok és az alkalmazásszintű gyorsítótárazás hosszú távú stratégiákként a gyakori olvasási adatok horizontális felskálázásához .

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 tippek alkalmazása.

Ha azonosítja azokat az eseteket, amikor a lekérdezések néha olyan végrehajtási tervet használnak, amely nem optimális a teljesítmény szempontjából, tekintse át a bizalmas 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 tippek. 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 alternatív teljesítményhangolási megoldás a gyakran futó lekérdezések RECOMPILE konzisztens teljesítményének biztosítása érdekében.

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. Csatlakozás az adatbázisba az SSMS-sel vagy az Azure Data Studió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 modellben növelheti 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. Az Azure SQL Database-t a DTU-alapú modellből a virtuális magalapú modellbe migrálhatja a vásárlási modellek közötti váltáshoz.

Kapcsolódó tartalom

További információ az Azure SQL Database monitorozásáról és teljesítményhangolásáról az alábbi cikkekben: