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 ismert okokat és megoldásokat tartalmaz a NoSQL API különböző 429-beli állapotkódhibáihoz. Ha a MongoDB API-t használja, tekintse meg a MongoDB-hez készült API gyakori hibáinak elhárítása című cikket az 16500-ás állapotkód hibakereséséhez.

A "Túl nagy kérelemmennyiség" kivétel, más néven a 429-as hibakód azt jelzi, hogy az Azure Cosmos DB-vel kapcsolatos 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, az írások és a lekérdezések bizonyos számú kérelemegységet (kérelemegységet) 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. Másodpercenként a használható kérelemegységek száma alaphelyzetbe áll.

Mielőtt műveletet hajt végre a kérelemegységek módosítására, fontos tisztában lenni a sebességkorlátozás alapvető okával, és kezelni a mögöttes problémát.

Tipp

Az ebben a cikkben található útmutató a kiosztott átviteli sebességet használó adatbázisokra és tárolókra vonatkozik , az automatikus skálázás és a manuális átviteli sebesség használatával.

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

A kérések száma nagy

Ez a leggyakoribb forgatókönyv. Ez akkor fordul elő, ha az adatműveletek által felhasznált kérelemegységek túllépik a kiosztott RU/s-t. Ha manuális átviteli sebességet használ, akkor ez akkor fordul elő, ha a kiosztott manuális átviteli sebességnél több RU/s-t használt fel. Ha automatikus skálázást használ, ez akkor fordul elő, ha a maximális kiosztott RU/s-nál többet fogyasztott. Ha például egy 400 RU/s manuális átviteli sebességgel rendelkező erőforrás van kiépítve, akkor 429 jelenik meg, 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 erőforrással rendelkezik (400 RU/s és 4000 RU/s között skálázható), akkor 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éréseket tartalmaznak, amelyek nem fejeződnek be sikeresen az olyan alkalmazáshibák miatt, mint például 400a , 412, , 449stb. A szabályozást vagy a használatot vizsgálva érdemes megvizsgálni, hogy megvá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 a (tényleges ütközést).

A kiosztott átviteli sebességről további információt a kiosztott átviteli sebesség az Azure Cosmos DB-ben című témakörben talál.

1. lépés: Ellenőrizze a metrikákat, és állapítsa meg a kérések százalékos arányát 429-gyel

A 429-ben megjelenő hibaüzenetek nem feltétlenül jelentik 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 maximálisan kihasználja a kiépített ru/s értéket.

Útmutató a kivizsgáláshoz

Állapítsa 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érések teljes számához képest. Az Azure Cosmos DB-fiókjából lépjen az Insights>Requests Total Requests> byStatus Code (Összes kérelem állapotkód alapján) területre. Szűrjön egy 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 a Azure Data Factory és a tömeges végrehajtói kódtár automatikusan újrapróbálkozott a kérésekkel a 429s rendszeren. Általában kilencszer próbálkoznak újra. Ennek eredményeképpen bár 429 válasz jelenhet meg a metrikákban, előfordulhat, hogy ezek a hibák még az alkalmazásnak sem lettek visszaadva.

Összes kérelem állapotkód szerint diagram, amely 429 és 2xx kérések számát mutatja.

Általában éles számítási feladatok esetén, ha a kérések 1–5%-a 429 válaszsal jelenik meg, és a végpontok közötti késés elfogadható, ez jó jel arra, hogy az RU/s teljes mértékben kihasznált. 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 adhat vissza, míg a teljes arány alacsony lehet.

Ha automatikus skálázást használ, 429 válasz jelenhet meg az adatbázisban vagy a tárolóban, 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 című szakaszt.

Az egyik gyakori kérdés a következő: "Miért látok 429 választ az Azure Monitor-metrikákban, de egyik sem a saját alkalmazásmonitorozásomban?" Ha az Azure Monitor-metrikák azt mutatják, hogy 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-k 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ént a 429-as állapotkód nem lesz visszaadva az alkalmazásnak. Ezekben az esetekben a 429 válaszok teljes 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 elérésű partíció akkor fordul elő, ha egy vagy néhány logikai partíciókulcs a nagyobb kérelemmennyiség miatt aránytalanul nagy mennyiségű ru/s-t használ fel. Ezt olyan partíciókulcs-kialakítás okozhatja, amely nem egyenletesen osztja el a kéréseket. Ez azt eredményezi, hogy sok kérést a rendszer a logikai (ami fizikai) partíciók egy kis részhalmazára irányít, amelyek "forró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 elérésű partíciók 429 válaszhoz és az átviteli sebesség nem hatékony használatához vezethetnek.

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

  • Rendelkezik egy tárolóval, amely IoT-eszközadatokat tárol a által particionált date, írási terhelést igénylő számítási feladatokhoz. Egyetlen dátum összes adata ugyanazon a logikai és fizikai partíción fog elhelyezkedni. Mivel a naponta írt összes adatnak ugyanaz a dátuma, ez minden nap gyakori elérésű partíciót eredményezne.
    • Ehelyett ebben a forgatókönyvben egy partíciókulcs, például id egy GUID vagy egy eszközazonosító, vagy egy szintetikus partíciókulcs , amely kombinálja id az értékeket, és date nagyobb számosságot eredményezne, és jobb kérésmennyiség-eloszlást eredményezne.
  • Több-bérlős forgatókönyve van, amelynek a tárolója particionálta a következőt tenantId: . Ha az egyik bérlő sokkal aktívabb, mint a többi, az egy gyakori elérésű 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óval fog rendelkezni.
    • Ebben az előző forgatókönyvben fontolja meg, hogy rendelkezik egy dedikált tárolóval a legnagyobb bérlőhöz, amelyet egy részletesebb tulajdonság, például UserIda particionált.

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

Ha ellenőrizni szeretné, hogy van-e gyakori elérésű partíció, keresse meg az Insights>átviteli sebesség>normalizált ru-használatát (%) PartitionKeyRangeID szerint. Szűrjön egy 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%-nál kisebbek), ez egy gyakori elérésű partíció jele lehet. További információ a normalizált kérelemegység-használat metrikájáról.

Normalizált kérelemegység-használat PartitionKeyRangeId diagramon egy gyakori elérésű 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 mintalekérdezés az egyes logikai partíciókulcsokon másodpercenként felhasznált összes kérelemegységet összegzi.

Fontos

A diagnosztikai naplók engedélyezése külön díjat von maga után a Log Analytics szolgáltatásért, amelynek számlázása a betöltött adatok mennyisége alapján történik. 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. A 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,míg a "Fabrikam" értékkel rendelkező logikai partíciókulcs kevesebb mint 600 RU/s-t fogyasztott. Ha ez a minta konzisztens volt abban az időszakban, amikor a sebességkorlátozás történt, az egy gyakori elérésű partíciót jelezne.

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

Tipp

Bármely számítási feladatban természetes eltérés lesz a kérelemkötetben a logikai partíciók között. Meg kell határoznia, hogy a gyakori elérésű partíciót a partíciókulcs kiválasztása (ami a kulcs módosítását igényelheti) vagy ideiglenes kiugrást okoz-e a számítási feladatok mintáinak természetes változása miatt.

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

Ha a kérelmek aránya magas, és nincs gyakori elérésű partíció:

Ha a sebességkorlátos kérelmek magas százaléka van, és van mögöttes gyakori elérésű 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ő helyben, ezért az adatokat egy másik partíciókulccsal rendelkező új tárolóba kell migrálni. 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 több átviteli sebességet biztosíthasson a gyakori elérésű partícióhoz. Ez nem ajánlott hosszú távú stratégiaként, mivel az ru/s túl nagy mértékű leépítéséhez és magasabb költségekhez vezet.
  • Rövid távon az átviteli sebesség partíciók közötti újraelosztási funkciójá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 a legnagyobb számú RU/s-t szeretné beállítani 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önálló PartitionKeyRangeId-ek számát 10 0000 RU/s-tal. Ha például 30 000 RU/s ki van építve és 5 fizikai partíció (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ával kapcsolatos ajánlott eljárásokról.

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

Kérelmek vizsgálata 429 válaszsal

Az Azure Diagnosztikai naplók használatával megállapíthatja, hogy mely kérések 429 választ adnak vissza, és hány kérelemegységet használnak fel. Ez a mintalekérdezés a perc szintjén összesül.

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. A 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 a dokumentum-létrehozási kérések percenkénti 30%-a volt korlátozva, és mindegyik kérelem átlagosan 17 kérelemegységet fogyasztott. 429-et tartalmazó kérések 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 és 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 a 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. Hangolja az indexelési szabályzatot úgy, hogy csak a szükséges tulajdonságokat indexelje. Ez csökkenti a létrehozási dokumentummű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
429 válasz a tárolt eljárások végrehajtására
  • A tárolt eljárások olyan műveletekhez készültek, 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 automatikus skálázással

A cikkben található ö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 lehetséges 429 válasz automatikus skálázással?"

Igen. Ez két fő forgatókönyvben fordulhat elő.

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 túllépi egy adatbázis vagy tároló manuális kiosztott átviteli sebességét.

2. forgatókönyv: Ha van egy gyakori elérésű partíció, azaz 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ést tartalmaz, lehetséges, hogy a mögöttes fizikai partíció túllépi az 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 elérésű partíciókhoz.

Ha például a 20 000 RU/s maximális átviteli sebessé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 méretezhető. Ha egy adott logikai partíciókulcson gyakori elérésű partíció volt, 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-használat 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 feladatoknál fordul elő, amelyek ideiglenes vagy időszakos használati csúcsokkal rendelkeznek. Automatikus skálázás használata esetén 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 egy 5 másodperces folyamatos időtartamon belül. Ez azért 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 kiugrások ne vezessenek felesleges skálázáshoz és magasabb költségekhez. Pillanatnyi kiugrások 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 kérelemegység-használati metrikák automatikus skálázással történő é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 rendszer által fenntartott ru-korlát vonatkozik, ezért az adatbázis vagy tároló kiosztott RU-jainak növelése nem lesz hatással, és nem ajánlott. Lásd: Vezérlősík szolgáltatáskorlátai.

Útmutató a kivizsgáláshoz

Lépjen az Insights>rendszer>metaadatainak kérései állapotkód alapján területre. Szűrjön egy adott adatbázisra és tárolóra, ha szükséges.

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, hogy alacsonyabb sebességgel küldje el ezeket a kéréseket.

  • Statikus Azure Cosmos DB-ügyfélpéldányok használata. A DocumentClient vagy a CosmosClient inicializálásakor az Azure Cosmos DB SDK lekéri a fiók metaadatait, beleértve a konzisztenciaszinttel, az adatbázisokkal, a tárolókkal, a partíciókkal és az ajánlatokkal kapcsolatos 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.

  • Az adatbázisok és tárolók nevének gyorsítótárazása. 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 CreateDatabaseQuery/CreateDocumentCollectionQuery, metaadat-hívásokat eredményeznek a szolgáltatásnak, 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

Ezt a 429-et a rendszer akkor adja vissza, ha a kérés átmeneti szolgáltatáshibával találkozik. Az ru/s növelése az adatbázison vagy tárolón nem lesz hatással, és nem ajánlott.

Ismételje meg a kérést. Ha a hiba néhány percig fennáll, küldjön egy támogatási jegyet a Azure Portal.

Következő lépések