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

Az Azure Cosmos DB túl magas kérelemmennyiség miatti kivételeinek (429-es hibáinak) diagnosztizálása és hibaelhárítása

  • Cikk

A KÖVETKEZŐRE VONATKOZIK: NoSQL

Ez a cikk a NoSQL API különböző 429-es állapotkódhibáinak ismert okait és megoldásait tartalmazza. Ha a MongoDB API-t használja, az 16500-es állapotkód hibakereséséről a MongoDB API gyakori hibáinak elhárítása című cikkben olvashat.

A "Túl nagy kérelemarány" kivétel, más néven a 429-as hibakód azt jelzi, hogy az Azure Cosmos DB-hez irányuló kérelmek száma korlátozott.

A kiosztott átviteli sebesség használatakor a számítási feladathoz szükséges kérelemegységekben (RU/s) mért átviteli sebességet állítja be. A szolgáltatáson végzett adatbázis-műveletek, például az olvasások, írások és lekérdezések bizonyos számú kérelemegységet (KÉRELEM) használnak fel. További információ a kérelemegységekről.

Egy adott másodpercben, ha a műveletek a kiosztott kérelemegységeknél többet használnak fel, az Azure Cosmos DB 429 kivételt ad vissza. Minden másodpercben a használható kérelemegységek száma alaphelyzetbe áll.

Mielőtt módosítanák az RU/s-t, fontos tisztában lenni a sebességkorlátozás alapvető okával, és kezelni az alapul szolgáló problémát.

Tipp.

A cikkben szereplő útmutatás a kiosztott átviteli sebességet használó adatbázisokra és tárolókra vonatkozik – az automatikus skálázásra és a manuális átviteli sebességre is.

Különböző hibaüzenetek felelnek meg a 429 kivétel különböző típusainak:

A kérések aránya nagy

Ez a leggyakoribb eset. Ez akkor fordul elő, ha az adatműveletek által felhasznált kérelemegységek túllépik a kiosztott ru/s számot. Ha manuális átviteli sebességet használ, ez akkor fordul elő, ha több RU/s-t fogyasztott, mint a kiosztott manuális átviteli sebesség. Ha automatikus skálázást használ, ez akkor fordul elő, ha a maximális kiosztott RU/s-nál többet használt fel. Ha például egy 400 RU/s manuális átviteli sebességgel rendelkező erőforrás van kiépítve, akkor a 429-et fogja látni, ha egyetlen másodperc alatt több mint 400 kérelemegységet használ fel. Ha 4000 RU/s automatikus skálázási maximális RU/s-val rendelkező erőforrással rendelkezik (400 RU/s és 4000 RU/s közötti skálázással), 429 válasz jelenik meg, ha egyetlen másodperc alatt több mint 4000 kérelemegységet használ fel.

Tipp.

A rendszer minden műveletet a felhasznált erőforrások száma alapján számít fel. Ezek a díjak kérelemegységekben vannak mérve. Ezek a díjak olyan kérelmeket tartalmaznak, amelyek alkalmazáshibák miatt nem fejeződnek be sikeresen, például 400, 412, 449stb. A szabályozást vagy a használatot vizsgálva érdemes megvizsgálni, hogy változott-e valamilyen minta a használatban, ami ezeknek a műveleteknek a növekedését eredményezné. Pontosabban ellenőrizze a címkéket 412 vagy 449 (tényleges ütközést).

A kiosztott átviteli sebességről további információt az Azure Cosmos DB kiosztott átviteli sebességével kapcsolatban talál.

1. lépés: Ellenőrizze a metrikákat a kérelmek százalékos arányának meghatározásához 429 hibával

A 429 hibaüzenet nem feltétlenül jelenti azt, hogy probléma van az adatbázissal vagy a tárolóval. A 429 válasz kis százaléka normális, függetlenül attól, hogy manuális vagy automatikus skálázási átviteli sebességet használ, és azt jelzi, hogy maximalizálja a kiépített ru/s értékét.

Útmutató a kivizsgáláshoz

Határozza meg, hogy az adatbázisra vagy tárolóra irányuló kérések hány százaléka eredményezett 429 választ a sikeres kérelmek teljes számához képest. Az Azure Cosmos DB-fiókjában lépjen az Insights>Requests total requests>by Status Code (Összes kérés összesen) elemre állapotkód alapján. Szűrés adott adatbázisra és tárolóra.

Alapértelmezés szerint az Azure Cosmos DB ügyféloldali SDK-k és adatimportáló eszközök, például az Azure Data Factory és a tömeges végrehajtói kódtár automatikusan újrapróbálkoznak a 429-eseken. Általában legfeljebb kilencszer próbálkoznak újra. Ennek eredményeképpen bár 429 válasz jelenhet meg a metrikákban, előfordulhat, hogy ezeket a hibákat nem is adták vissza az alkalmazásnak.

Összes kérelem állapotkód szerinti diagramja, amely a 429-es és a 2xx-es kérelmek számát jeleníti meg.

Az éles számítási feladatok esetében általában, ha a kérelmek 1–5%-át látja 429 válaszsal, és a végpontok közötti késés elfogadható, ez jó jel arra, hogy a kérelemegységek teljes mértékben kihasználva vannak. Semmit nem kell tenni. Ellenkező esetben lépjen a következő hibaelhárítási lépésekre.

Fontos

Ez az 1–5%-os tartomány feltételezi, hogy a fiókpartíciók egyenletesen vannak elosztva. Ha a partíciók nem egyenletesen oszlanak el, a problémapartíció nagy mennyiségű 429 hibát eredményezhet, míg a teljes arány alacsony lehet.

Ha automatikus skálázást használ, 429 válasz jeleníthető meg az adatbázison vagy a tárolón, még akkor is, ha az RU/s nem volt a maximális RU/s-ra skálázva. A magyarázatért tekintse meg az automatikus skálázást tartalmazó, nagy kérelemarányú szakaszt.

Az egyik gyakori kérdés a következő: "Miért látok 429 választ az Azure Monitor metrikáiban, de egyik sem a saját alkalmazásmonitorozásomban?" Ha az Azure Monitor-metrikák szerint 429 válasza van, de nem látott semmit a saját alkalmazásában, ennek az az oka, hogy alapértelmezés szerint az Azure Cosmos DB ügyféloldali SDK-jai automatically retried internally on the 429 responses és a kérés sikeres volt a későbbi újrapróbálkozások során. Ennek eredményeképpen a rendszer nem adja vissza a 429-as állapotkódot az alkalmazásnak. Ezekben az esetekben a 429 válaszok összesített aránya általában minimális, és biztonságosan figyelmen kívül hagyható, feltéve, hogy a teljes arány 1–5% között van, és a végpontok közötti késés elfogadható az alkalmazás számára.

2. lépés: Annak megállapítása, hogy van-e gyakori elérésű partíció

Gyakori partíció akkor fordul elő, ha egy vagy néhány logikai partíciókulcs aránytalanul nagy mennyiségű ru/s-t használ fel a nagyobb kérelemmennyiség miatt. Ezt olyan partíciókulcs-kialakítás okozhatja, amely nem egyenletesen osztja el a kéréseket. Ez sok kérést eredményez, amelyek a logikai (ami fizikai) partíciók egy kis részhalmazára irányulnak, amelyek "gyakori" állapotúvá válnak. Mivel egy logikai partíció összes adata egy fizikai partíción található, és a teljes RU/s egyenletesen oszlik el a fizikai partíciók között, a gyakori partíciók 429 választ és az átviteli sebesség nem hatékony használatát eredményezhetik.

Íme néhány példa a particionálási stratégiákra, amelyek gyakori partíciókhoz vezetnek:

  • Rendelkezik egy tárolóval, amely IoT-eszközadatokat tárol egy olyan írási terheléshez, amelyet dateparticionált a rendszer. Az egyetlen dátumhoz tartozó összes adat ugyanazon a logikai és fizikai partíción fog elhelyezkedni. Mivel a naponta írt összes adatnak ugyanaz a dátuma, ez minden nap gyakori partíciót eredményezne.
    • Ehelyett ebben a forgatókönyvben egy partíciókulcsot(például id GUID-t vagy eszközazonosítót) vagy szintetikus partíciókulcsot kombinál, id és date magasabb számosságot eredményezne az értékekben, és jobb elosztást eredményezne a kérésmennyiségben.
  • Több-bérlős forgatókönyve van egy tároló particionálásával tenantId. Ha az egyik bérlő sokkal aktívabb, mint a többi, az egy gyakori partíciót eredményez. Ha például a legnagyobb bérlő 100 000 felhasználóval rendelkezik, de a legtöbb bérlő 10-nél kevesebb felhasználóval rendelkezik, a particionáláskor tenantIDegy gyakori elérésű partíciót fog létrehozni.
    • Ebben az előző forgatókönyvben fontolja meg, hogy rendelkezik egy dedikált tárolóval a legnagyobb bérlő számára, amelyet egy részletesebb tulajdonság, például UserIda .

A gyakori elérésű partíció azonosítása

Ha ellenőrizni szeretné, hogy van-e gyakori partíció, keresse meg az Insights>átviteli sebesség>normalizált RU-használatát (%) PartitionKeyRangeID szerint. Szűrés adott adatbázisra és tárolóra.

Minden PartitionKeyRangeId egy fizikai partícióra van leképzve. Ha van egy PartitionKeyRangeId, amely sokkal magasabb normalizált RU-használattal rendelkezik, mint mások (például az egyik következetesen 100%-os, míg mások 30%-os vagy kisebb), ez a gyakori elérésű partíciók jele lehet. További információ a normalizált ru-használat metrikájáról.

Normalizált RU-használat a PartitionKeyRangeId diagramon egy gyakori partícióval.

Annak megtekintéséhez, hogy mely logikai partíciókulcsok használják a legtöbb RU/s-t, használja az Azure Diagnosztikai naplókat. Ez a minta lekérdezés összegzi az egyes logikai partíciókulcsokon másodpercenként felhasznált összes kérelemegységet.

Fontos

A diagnosztikai naplók engedélyezése külön díjat von maga után a Log Analytics szolgáltatásért, amely a betöltött adatok mennyisége alapján kerül számlázásra. Javasoljuk, hogy korlátozott ideig kapcsolja be a diagnosztikai naplókat a hibakereséshez, és kapcsolja ki, ha már nincs rá szükség. Részletekért tekintse meg a díjszabási oldalt .

 CDBPartitionKeyRUConsumption
 | where TimeGenerated >= ago(24hour)
 | where CollectionName == "CollectionName"
 | where isnotempty(PartitionKey)
 // Sum total request units consumed by logical partition key for each second
 | summarize sum(RequestCharge) by PartitionKey, OperationName, bin(TimeGenerated, 1s)
 | order by sum_RequestCharge desc

Ez a mintakimenet azt mutatja, hogy egy adott percben a "Contoso" értékkel rendelkező logikai partíciókulcs körülbelül 12 000 RU/s-ot, míg a "Fabrikam" értéket tartalmazó logikai partíciókulcs kevesebb mint 600 RU/s-ot fogyasztott. Ha ez a minta konzisztens volt abban az időszakban, amikor sebességkorlátozás történt, ez egy gyakori partíciót jelezne.

A legtöbb kérelemegységet másodpercenként használó logikai partíciókulcsok.

Tipp.

Bármely számítási feladatban a kérelemmennyiség természetes módon változik a logikai partíciók között. Meg kell határoznia, hogy a gyakori partíciót alapvető eltérés okozza-e a partíciókulcs kiválasztása miatt (ami szükségessé teheti a kulcs módosítását) vagy a számítási feladatok mintáinak természetes változása miatti ideiglenes kiugró értéket.

Tekintse át a jó partíciókulcs kiválasztására vonatkozó útmutatót.

Ha a korlátozott sebességű kérések nagy százalékban vannak megadva, és nincs gyakori elérésű partíció:

Ha a korlátozott sebességű kérelmek magas százaléka van, és van mögöttes gyakori partíció:

  • Hosszú távon a legjobb költség és teljesítmény érdekében fontolja meg a partíciókulcs módosítását. A partíciókulcs nem frissíthető a helyén, ezért ehhez át kell telepíteni az adatokat egy másik partíciókulcsot tartalmazó új tárolóba. Az Azure Cosmos DB ebből a célból támogatja az élőadat-migrálási eszközt.
  • Rövid távon ideiglenesen növelheti az erőforrás teljes RU/s-ját, hogy nagyobb átviteli sebességet biztosíthasson a gyakori elérésű partícióhoz. Ez nem ajánlott hosszú távú stratégiaként, mivel a ru/s túlterjeszkedéséhez és magasabb költségekhez vezet.
  • Rövid távon a partíciók közötti átviteli sebesség újraelosztásával (előzetes verzió) több RU/s-t rendelhet a gyakori elérésű fizikai partícióhoz. Ez csak akkor ajánlott, ha a gyakori elérésű fizikai partíció kiszámítható és konzisztens.

Tipp.

Az átviteli sebesség növelésekor a vertikális felskálázási művelet azonnal befejeződik, vagy akár 5–6 órát is igénybe vehet, attól függően, hogy hány RU/s-ra szeretne felskálázni. Ha szeretné tudni, hogy a legnagyobb számú RU/s állítható be az aszinkron vertikális felskálázási művelet aktiválása nélkül (amelyhez az Azure Cosmos DB-nek több fizikai partíciót kell kiépítenie), szorozza meg a különböző PartitionKeyRangeId-ek számát 10 0000 RU/s-val. Ha például 30 000 RU/s kiépítési és 5 fizikai partícióval rendelkezik (fizikai partíciónként 6000 RU/s van lefoglalva), akkor egy azonnali vertikális felskálázási műveletben 50 000 RU/s-ra (fizikai partíciónként 10 000 RU/s) növelhető. Az 50 000 RU/s-ra való >növeléséhez aszinkron vertikális felskálázási művelet szükséges. További információ a kiosztott átviteli sebesség (RU/s) skálázásának ajánlott eljárásairól.

3. lépés: Annak meghatározása, hogy milyen kérések 429 választ adnak vissza

Kérelmek vizsgálata 429 válaszsal

Az Azure Diagnosztikai naplók segítségével megállapíthatja, hogy mely kérések 429 választ adnak vissza, és hány kérelemegységet használnak fel. Ez a minta lekérdezés a percenkénti szinten összesít.

Fontos

A diagnosztikai naplók engedélyezése külön díjat von maga után a Log Analytics szolgáltatásért, amely a betöltött adatok mennyisége alapján kerül számlázásra. Javasoljuk, hogy korlátozott ideig kapcsolja be a diagnosztikai naplókat a hibakereséshez, és kapcsolja ki, ha már nincs rá szükség. Részletekért tekintse meg a díjszabási oldalt .

 CDBDataPlaneRequests
 | where TimeGenerated >= ago(24h)
 | summarize throttledOperations = dcountif(ActivityId, StatusCode == 429), totalOperations = dcount(ActivityId), totalConsumedRUPerMinute = sum(RequestCharge) by DatabaseName, CollectionName, OperationName, RequestResourceType, bin(TimeGenerated, 1min)
 | extend averageRUPerOperation = 1.0 * totalConsumedRUPerMinute / totalOperations
 | extend fractionOf429s = 1.0 * throttledOperations / totalOperations
 | order by fractionOf429s desc

Ez a mintakimenet például azt mutatja, hogy percenként a Dokumentum létrehozása kérések 30%-a volt korlátozva, és minden kérelem átlagosan 17 kérelemegységet használt fel. A 429-et tartalmazó kérelmek a diagnosztikai naplókban.

Az Azure Cosmos DB kapacitástervezőjének használata

Az Azure Cosmos DB kapacitástervezővel megismerheti, hogy mi a legjobban kiosztott átviteli sebesség a számítási feladat (a műveletek mennyisége és típusa, valamint a dokumentumok mérete) alapján. A számítások további testreszabásához adjon meg mintaadatokat a pontosabb becslés érdekében.

429 válasz dokumentumkérelmek létrehozására, cseréjére vagy frissítésére
  • A NoSQL API-ban alapértelmezés szerint minden tulajdonság indexelve van. Állítsa be az indexelési szabályzatot úgy, hogy csak a szükséges tulajdonságokat indexelje. Ez csökkenti a dokumentum-létrehozási művelethez szükséges kérelemegységeket, ami csökkenti annak valószínűségét, hogy 429 válasz jelenik meg, vagy nagyobb műveleteket érhet el másodpercenként ugyanennyi kiosztott RU/s esetén.
429 válasz a lekérdezési dokumentumkérésekre
  • Kövesse az útmutatást a magas RU-díjú lekérdezések hibaelhárításához
429 válasz a tárolt eljárások végrehajtására
  • A tárolt eljárások olyan műveletekre szolgálnak, amelyek egy partíciókulcs-értéken keresztüli írási tranzakciókat igényelnek. Nem ajánlott tárolt eljárásokat használni nagy számú olvasási vagy lekérdezési művelethez. A legjobb teljesítmény érdekében ezeket az olvasási vagy lekérdezési műveleteket az ügyféloldalon kell elvégezni az Azure Cosmos DB SDK-k használatával.

A kérések aránya nagy az automatikus skálázással

A cikkben szereplő összes útmutató a manuális és az automatikus skálázási átviteli sebességre egyaránt vonatkozik.

Az automatikus skálázás használatakor gyakori kérdés a következő: "Továbbra is 429 válasz jelenik meg automatikus skálázással?"

Igen. Ennek két fő forgatókönyve lehet.

1. forgatókönyv: Ha a teljes felhasznált RU/s meghaladja az adatbázis vagy tároló maximális RU/s-ját, a szolgáltatás ennek megfelelően szabályozza a kéréseket. Ez hasonló ahhoz, hogy egy adatbázis vagy tároló teljes manuális kiosztott átviteli sebességét túllépi.

2. forgatókönyv: Ha van egy gyakori partíció, vagyis egy logikai partíciókulcs-érték, amely a többi partíciókulcs-értékhez képest aránytalanul nagyobb mennyiségű kéréssel rendelkezik, lehetséges, hogy a mögöttes fizikai partíció túllépi a ru/s költségvetését. A gyakori hozzáférésű partíciók elkerülésének ajánlott eljárása egy megfelelő partíciókulcs kiválasztása, amellyel a tárterület és az átviteli sebesség egyenlően osztható ki. Ez hasonló a manuális átviteli sebesség használatakor használt gyakori partíciókhoz.

Ha például a 20 000 RU/s maximális átviteli sebesség lehetőséget választja, és 200 GB tárterülettel rendelkezik négy fizikai partícióval, minden fizikai partíció automatikusan 5000 RU/s-ig skálázható. Ha egy adott logikai partíciókulcson gyakori partíció található, 429 válasz jelenik meg, ha a mögöttes fizikai partíció meghaladja az 5000 RU/s értéket, azaz meghaladja a 100%-os normalizált kihasználtságot.

A forgatókönyvek hibakereséséhez kövesse az 1. lépés, a 2. és a 3. lépés útmutatását.

Egy másik gyakori kérdés, hogy miért normalizált RU felhasználás 100%, de az automatikus skálázás nem skálázható a maximális RU/s?

Ez általában olyan számítási feladatok esetében fordul elő, amelyek kihasználtsága ideiglenes vagy időszakos. Automatikus skálázás használatakor az Azure Cosmos DB csak akkor skálázza az RU/s-t a maximális átviteli sebességre, ha a normalizált ru-használat 100%-os tartós, folyamatos időtartamon keresztül, 5 másodperces időközönként. Ez annak érdekében történik, hogy a skálázási logika költségbarát legyen a felhasználó számára, mivel biztosítja, hogy az egyszeri, pillanatnyi csúcsok ne vezessenek szükségtelen skálázáshoz és magasabb költségekhez. Pillanatnyi kiugró értékek esetén a rendszer általában a korábban ru/s-ra skálázott értéknél magasabb értékre skálázható, de alacsonyabbra, mint a maximális RU/s. További információ a normalizált RU-használati metrikák automatikus skálázással való értelmezéséről.

A metaadat-kérelmek sebességkorlátozása

A metaadatok sebességének korlátozása akkor fordulhat elő, ha nagy mennyiségű metaadat-műveletet hajt végre adatbázisokon és/vagy tárolókon. A metaadat-műveletek a következők:

  • Tároló vagy adatbázis létrehozása, olvasása, frissítése vagy törlése
  • Adatbázisok vagy tárolók listázása egy Azure Cosmos DB-fiókban
  • Ajánlatok lekérdezése az aktuális kiosztott átviteli sebesség megtekintéséhez

Ezekre a műveletekre a rendszer által fenntartott ru-korlát vonatkozik, ezért az adatbázis vagy tároló kiosztott RU/s-jainak növelése nem lesz hatással, és nem ajánlott. Lásd: Vezérlősík szolgáltatáskorlátjai.

Útmutató a kivizsgáláshoz

Lépjen az Insights>rendszer>metaadat-kérelmeihez állapotkód alapján. Szükség esetén szűrjön egy adott adatbázisra és tárolóra.

Metaadat-kérelmek állapotkóddiagram alapján az Insightsban.

  • Ha az alkalmazásnak metaadat-műveleteket kell végrehajtania, fontolja meg egy visszalépési szabályzat implementálását, amely alacsonyabb sebességgel küldi el ezeket a kéréseket.

  • Használjon statikus Azure Cosmos DB-ügyfélpéldányokat. A DocumentClient vagy a CosmosClient inicializálásakor az Azure Cosmos DB SDK lekéri a fiók metaadatait, beleértve a konzisztencia szintjére, az adatbázisokra, a tárolókra, a partíciókra és az ajánlatokra vonatkozó információkat. Ez az inicializálás sok kérelemegységet használhat fel, és ritkán kell elvégezni. Egyetlen DocumentClient-példányt használjon az alkalmazás teljes élettartama alatt.

  • Gyorsítótárazza az adatbázisok és tárolók nevét. Kérje le az adatbázisok és tárolók nevét a konfigurációból, vagy gyorsítótárazza őket az indításkor. Az olyan hívások, mint a ReadDatabaseAsync/ReadDocumentCollectionAsync vagy a CreateDatabaseQuery/CreateDocumentCollectionQuery, metaadat-hívásokat eredményeznek a szolgáltatáshoz, amelyek a rendszer által fenntartott RU-korlátból származnak. Ezeket a műveleteket ritkán kell végrehajtani.

Sebességkorlátozás átmeneti szolgáltatáshiba miatt

Ez a 429-hiba akkor jelenik meg, ha a kérés átmeneti szolgáltatáshibával találkozik. Az adatbázis vagy tároló ru/s-jának növelése nem lesz hatással, és nem ajánlott.

Ismételje meg a kérést. Ha a hiba több percig is fennáll, küldjön támogatási jegyet az Azure Portalról.

Következő lépések