Teljesítményforgatókönyvek felfedezése

  • 5 perc

A teljesítményeszközök és képességek használatának eldöntéséhez fontos, hogy forgatókönyveken keresztül vizsgálja meg az Azure SQL teljesítményét.

A gyakori teljesítményforgatókönyvek ismertetése

Az SQL Server teljesítményproblémáinak hibaelhárításának egyik gyakori módszere annak vizsgálata, hogy egy teljesítményprobléma fut-e (magas CPU-használat) vagy várakozik (egy erőforráson). Az alábbi ábrán látható döntési fával meghatározható, hogy az SQL Server teljesítményével kapcsolatos probléma futó vagy várakozó-e, illetve az is, hogy miként állapítható meg az ok és a megoldás a teljesítménynövelő eszközökkel.

A futás és a várakozás diagramja.

Először az általános erőforrás-használattal foglalkozunk. Egy szabványos SQL Server-telepítéshez olyan eszközöket használhat, mint a Windows teljesítményfigyelője vagy a Linux felső része. Az Azure SQL-hez a következő módszereket használhatja:

  • Azure Portal/PowerShell/riasztások

    A Azure Monitor integrált metrikákkal rendelkezik az Azure SQL erőforrás-használatának megtekintéséhez. Az erőforrás-használati feltételek figyeléséhez riasztásokat is beállíthat.

  • sys.dm_db_resource_stats

    Az Azure SQL Database esetében ezt a DMV-t megtekintve láthatja az adatbázispéldány processzor-, memória- és I/O-erőforráshasználatát. A DMV 15 másodpercenként készíti pillanatképet ezekről az adatokról.

  • sys.server_resource_stats

    Ez a DMV ugyanúgy viselkedik, mint a sys.dm_db_resource_stats, de az SQL Managed Instance erőforrás-felhasználásának megtekintésére szolgál a processzorra, a memóriára és az I/O-ra vonatkozóan. Ez a DMV szintén 15 másodpercenként készít pillanatképet.

  • sys.dm_user_db_resource_governance

    Az Azure SQL Database esetében ez a DMV az aktuális adatbázis vagy rugalmas készlet erőforrás-szabályozási mechanizmusai által használt tényleges konfigurációs és kapacitásbeállításokat adja vissza.

  • sys.dm_instance_resource_governance

    A felügyelt Azure SQL-példány esetében ez a DMV a jelenlegi felügyelt SQL-példányhoz hasonló sys.dm_user_db_resource_governanceadatokat ad vissza.

Futás

Ha azt állapította meg, hogy a problémát a magas processzorhasználat jelenti, ezt futó forgatókönyvnek nevezzük. A futó forgatókönyvek olyan lekérdezéseket tartalmazhatnak, amelyek fordítás vagy végrehajtás révén használnak erőforrásokat. A következő eszközökkel végezzen további elemzést:

  • Lekérdezéstár

    Az SSMS a Legnagyobb fogyasztású erőforrásokra vonatkozó jelentéseivel, a Lekérdezéstár katalógusnézeteivel vagy az Azure Portal Lekérdezési terheléselemzőjével (csak az Azure SQL Database esetén) keresheti meg, hogy mely lekérdezések fogyasztják a legtöbb processzor-erőforrást.

  • sys.dm_exec_requests

    Az Azure SQL ezen DMV-jével szerezheti be az aktív lekérdezések állapotának pillanatképét. Keressen olyan lekérdezéseket, amelyek állapota RUNNABLE és várakozási típusa SOS_SCHEDULER_YIELD van, és ellenőrizze, hogy elegendő processzorkapacitással rendelkezik-e.

  • sys.dm_exec_query_stats

    Ez a DMV a lekérdezéstárhoz hasonlóan a legtöbb erőforrást használó lekérdezések megkereséséhez használható. Ez csak gyorsítótárazott lekérdezési csomagokhoz érhető el, míg a Lekérdezéstár állandó előzményrekordot biztosít a teljesítményről. Ez a DMV azt is lehetővé teszi, hogy megkeresse a gyorsítótárazott lekérdezések lekérdezéstervét.

  • sys.dm_exec_procedure_stats

    Ez a DMV hasonló információkat nyújt, mint a sys.dm_exec_query_stats, de itt a teljesítménnyel kapcsolatos információk a tárolt eljárás szintjén tekinthetők meg.

    Miután meghatározta, hogy melyik lekérdezés vagy lekérdezések használják a legtöbb erőforrást, előfordulhat, hogy meg kell vizsgálnia, hogy elegendő processzor-erőforrással rendelkezik-e a számítási feladatokhoz. Előfordulhat, hogy hibakeresést kell végeznie a lekérdezéstervek kapcsán, például egyszerűsített lekérdezésprofil-készítéssel, SET-utasításokkal, a lekérdezéstárral vagy bővítettesemény-nyomkövetéssel.

Várakozás

Ha úgy tűnik, hogy a problémát nem a magas processzorhasználat jelenti, akkor lehetséges, hogy a teljesítménnyel kapcsolatos probléma egy erőforrásra való várakozással kapcsolatos. Többek között a következő forgatókönyvek kapcsolódnak az erőforrásokra való várakozáshoz:

  • I/O-várakozások
  • Zárolási várakozások
  • Reteszes zárolási várakozások
  • Pufferkészlet korlátai
  • Memóriabeli ideiglenes tárak
  • Terv gyorsítótárának kiürítése

A várakozási forgatókönyvek elemzéséhez általában a következő eszközöket kell megvizsgálnia:

  • sys.dm_os_wait_stats

    Ezzel a DMV-vel megtekintheti az adatbázis vagy a példány leggyakoribb várakozástípusait. Ez a leggyakoribb várakozástípusoktól függően útmutatást nyújthat az elvégzendő művelettel kapcsolatban.

  • sys.dm_exec_requests

    Ezzel a DMV-t használva konkrét várakozási típusokat kereshet az aktív lekérdezésekhez, hogy lássa, milyen erőforrásra várnak. Ez lehet egy, a többi felhasználó zárolásaira váró standard letiltási forgatókönyv.

  • sys.dm_os_waiting_tasks

    Ezzel a DMV-sel megkeresheti egy adott feladat várakozási típusait egy jelenleg futó lekérdezéshez, talán azért, hogy megtudja, miért tart a szokásosnál hosszabb ideig. sys.dm_os_waiting_tasks azokat az élő várakozási statisztikákat tartalmazza, amelyeket sys.dm_os_wait_stats az idő függvényében összesít.

  • Lekérdezéstár

    A Lekérdezéstár olyan jelentéseket és katalógusnézeteket biztosít, amelyek a lekérdezésterv végrehajtása leggyakoribb várakozásainak összesítését jelenítik meg. Fontos tudni, hogy a CPU várakozás egyenértékű egy futófolyamat problémával.

Az Azure SQL-re vonatkozó forgatókönyvek

Vannak olyan teljesítménnyel kapcsolatos futási és várakozási forgatókönyvek, amelyek kifejezetten az Azure SQL-re jellemzőek. Ilyen a naplószabályozás, a feldolgozói korlátok, az üzletileg kritikus szolgáltatásszintek használatakor tapasztalt várakozások és a rugalmas skálázású üzembe helyezésre jellemző várakozások.

Naplószabályozás

Az Azure SQL naplószabályozás használatával kényszeríti ki a tranzakciós naplók használatára vonatkozó erőforráskorlátokat. Előfordulhat, hogy szükség van a kényszerítésre az erőforráskorlátok és az ígért SLA biztosítása érdekében. A naplószabályozás a következő várakozástípusok esetén figyelhető meg:

  • LOG_RATE_GOVERNOR: várakozás az Azure SQL Database-hez
  • POOL_LOG_RATE_GOVERNOR: várakozás a rugalmas készletekre
  • INSTANCE_LOG_GOVERNOR: várakozások a felügyelt Azure SQL-példányra
  • HADR_THROTTLE_LOG_RATE*: várakozás a üzletileg kritikus és a georeplikációs késésre

Feldolgozói korlátok

Az SQL Server szálakból álló feldolgozói készletet használ, de a feldolgozók maximális száma korlátozott. A nagy számú egyidejű felhasználóval rendelkező alkalmazások megközelíthetik az Azure SQL Database és a felügyelt SQL-példány esetében kikényszerített feldolgozói korlátokat:

  • Az Azure SQL Database a szolgáltatásszinttől és a mérettől függő korlátokkal rendelkezik. Ha meghaladja ezt a korlátot, az új lekérdezések hibaüzenetet kapnak.
  • Jelenleg a felügyelt SQL-példányok használják max worker threads, így a korlátot túllépő feldolgozók várakozásokat láthatnak THREADPOOL .

Üzletileg kritikus HADR várakozások

Ha üzletileg kritikus szolgáltatásszintet használ, előfordulhat, hogy váratlanul a következő várakozástípusok merülnek fel:

  • HADR_SYNC_COMMIT
  • HADR_DATABASE_FLOW_CONTROL
  • HADR_THROTTLE_LOG_RATE_SEND_RECV

Bár lehet, hogy ezek a várakozások nem lassítják le az alkalmazást, előfordulhat, hogy nem számít rájuk. Általában egy Always On rendelkezésreállási csoport használatára vonatkoznak. Az üzletileg kritikus szintek a rendelkezésreállási csoportok technológiáit használják az üzletileg kritikus szolgáltatásszint SLA- és rendelkezésreállási funkcióinak implementálásához, így ezekre a várakozástípusokra számítani lehet. A hosszú várakozási idő szűk keresztmetszetet jelezhet, például az I/O-késést vagy a replikált másolat lemaradását.

rugalmas skálázás

A Hyperscale architektúra olyan egyedi várakozási típusokat eredményezhet, amelyek RBIO előtaggal vannak ellátva (ami a naplószabályozás lehetséges jele lehet). Emellett a DMV-k, a katalógusnézetek és a kiterjesztett események is javulnak, így megjeleníthetők a lapkiszolgáló olvasási metrikái.

A következő gyakorlatban megtanulhatja, hogyan figyelheti és oldhatja meg az Azure SQL teljesítményproblémáját az ebben a leckében megszerzett eszközökkel és ismeretekkel.