Diagnostika a řešení potíží s výjimkami příliš velkého počtu požadavků služby Azure Cosmos DB (429)

PLATÍ PRO: SQL API

Tento článek obsahuje známé příčiny a řešení různých chyb stavového kódu 429 pro SQL API. Pokud používáte rozhraní API pro MongoDB, najdete informace o ladění stavového kódu 16500 v článku Řešení běžných problémů v rozhraní API pro MongoDB.

Výjimka Frekvence požadavků je příliš velká, označovaná také jako kód chyby 429, značí, že vaše požadavky na službu Azure Cosmos DB jsou rychlostně omezené.

Při použití zřízené propustnosti nastavíte propustnost změřenou v jednotkách žádostí za sekundu (RU/s) požadovaných pro vaši úlohu. Databázové operace se službou, jako jsou čtení, zápisy a dotazy, spotřebovávají určité množství jednotek žádostí (RU). Přečtěte si další informace o jednotkách žádostí.

Pokud v dané sekundě operace spotřebovávají více než zřízené jednotky žádostí, Azure Cosmos DB vrátí výjimku 429. Počet jednotek žádosti, které je možné použít, se každou sekundu resetuje.

Než začnete se změnou RU/s jednat, je důležité pochopit hlavní příčinu omezování rychlosti a vyřešit základní problém.

Existují různé chybové zprávy, které odpovídají různým typům výjimek 429:

Frekvence požadavků je velká.

Toto je nejběžnější scénář. K tomu dochází v případě, že jednotky žádostí spotřebované operacemi s daty překročí zřízený počet RU/s.

Krok 1: Kontrola metrik a určení procenta požadavků s chybou 429

Zobrazení chybových zpráv 429 nemusí nutně znamenat, že došlo k problému s vaší databází nebo kontejnerem.

Postup prošetření

Zjistěte, jaké procento vašich požadavků na databázi nebo kontejner v porovnání s celkovým početem úspěšných požadavků vedlo k 429. V okně účtu Azure Cosmos DB přejděte na stránku Přehledy Requests Total Requests by Status Code (Požadavky celkem > > podle stavového kódu). Vyfiltrujte konkrétní databázi a kontejner.

Ve výchozím nastavení klientské sady SDK služby Azure Cosmos DB a nástroje pro import dat, jako je Azure Data Factory a knihovna Bulk Executor, automaticky zopakují požadavky na chyby 429. Obvykle to zkusí až 9krát. V důsledku toho se v metrikách mohou zobrazit chyby 429, ale tyto chyby se nemusí do vaší aplikace vrátit.

Graf celkových požadavků podle stavového kódu, který zobrazuje počet požadavků 429 a 2xx.

Obecně platí, že pokud u produkčních úloh vidíte mezi 1–5 % požadavků s 429 a celkovou latencí je přijatelná, jedná se o funkční známku toho, že se RU/s plně využívají. Nevyžaduje se žádná akce. V opačném případě přejděte k dalšímu postupu při řešení potíží.

Krok 2: Určení, jestli existuje horký oddíl

Horký oddíl nastane, když jeden nebo několik klíčů logických oddílů spotřebovává neúměrné množství celkového počtu RU/s kvůli vyššímu objemu požadavků. Příčinou může být návrh klíče oddílu, který žádosti rovnoměrně nesměruje. Výsledkem je, že mnoho požadavků se směruje na malou podmnožinu logických oddílů (což znamená fyzické), které se stanou "horkými". Vzhledem k tomu, že se všechna data pro logický oddíl nacházejí v jednom fyzickém oddílu a celkový počet RU/s je rovnoměrně rozdělen mezi fyzické oddíly, může horký oddíl vést k problémům 429 a neefektivnímu využití propustnosti.

Tady je několik příkladů strategií dělení, které vedou k horkým oddílům:

  • Máte kontejner, který ukládá data zařízení IoT pro úlohy náročné na zápis dělené pomocí date . Všechna data pro jedno datum se budou nacházet ve stejném logickém a fyzickém oddílu. Vzhledem k tomu, že všechna data zapisaná každý den mají stejné datum, výsledkem by byl každý den horký oddíl.
    • V tomto scénáři by klíč oddílu jako (identifikátor GUID nebo ID zařízení) nebo syntetické klíče oddílu kombinující a přinesl vyšší kardinalitu hodnot a lepší distribuci svazku id id date žádosti.
  • Máte scénář s více tenanty a kontejnerem rozdělený podle tenantId . Pokud je jeden tenant výrazně aktivnější než druhý, výsledkem je horký oddíl. Pokud má například největší tenant 100 000 uživatelů, ale většina tenantů má méně než 10 uživatelů, budete mít horký oddíl při dělení podle tenantID .
    • V tomto předchozím scénáři zvažte vytvoření vyhrazeného kontejneru pro největšího tenanta rozděleného podle členitější vlastnosti, jako je UserId .

Jak identifikovat horký oddíl

Pokud chcete ověřit, jestli existuje horký oddíl, přejděte Přehledy Normalizovaná spotřeba RU (%) podle > > ID rozsahu klíčů oddílů. Vyfiltrujte konkrétní databázi a kontejner.

Každý PartitionKeyRangeId se mapuje na jeden fyzický oddíl. Pokud existuje jedno ID rozsahu klíčů oddílů, které má výrazně vyšší normalizovanou spotřebu RU než jiné (například jeden je konzistentně na 100 %, ale jiné mají 30 % nebo méně), může to být známka horkého oddílu. Přečtěte si další informace o metrikě Normalizovaná spotřeba RU.

Graf normalizované spotřeby RU podle ID rozsahu klíčů oddílů s horkým oddílem

Pokud chcete zobrazit, které klíče logických oddílů spotřebovávají nejvíce RU/s, použijte diagnostické protokoly Azure. Tento ukázkový dotaz sečte celkový počet spotřebovaných jednotek žádostí za sekundu pro každý logický klíč oddílu.

Důležité

Za povolení diagnostických protokolů se účtují samostatné poplatky za službu Log Analytics, která se účtuje na základě objemu ingestovaných dat. Doporučujeme zapnout diagnostické protokoly po omezenou dobu pro ladění a vypnout, pokud už nejsou potřeba. Podrobnosti najdete na stránce s cenami.

AzureDiagnostics
| where TimeGenerated >= ago(24hour)
| where Category == "PartitionKeyRUConsumption"
| where collectionName_s == "CollectionName" 
| where isnotempty(partitionKey_s)
// Sum total request units consumed by logical partition key for each second
| summarize sum(todouble(requestCharge_s)) by partitionKey_s, operationType_s, bin(TimeGenerated, 1s)
| order by sum_requestCharge_s desc

Tento ukázkový výstup ukazuje, že v konkrétní minutě spotřeboval logický klíč oddílu s hodnotou Contoso přibližně 12 000 RU/s, zatímco logický klíč oddílu s hodnotou Fabrikam spotřeboval méně než 600 RU/s. Pokud by byl tento model konzistentní během časového období, kdy došlo k omezování rychlosti, značí to horký oddíl.

Klíče logických oddílů, které spotřebovávají nejvíce jednotek žádostí za sekundu.

Tip

U všech úloh se objem požadavků napříč logickými oddíly přirozeně kolísá. Měli byste určit, jestli je horký oddíl způsoben základní nekosí kvůli výběru klíče oddílu (který může vyžadovat změnu klíče) nebo dočasnou špičku kvůli přirozené variaci vzorů úloh.

Prohlédněte si pokyny, jak zvolit dobrý klíč oddílu.

Pokud existuje vysoké procento požadavků s omezenou rychlostí a žádný horký oddíl:

  • Počet RU/s databáze nebo kontejneru můžete zvýšit pomocí klientských sdk, Azure Portal, PowerShellu, rozhraní příkazového řádku nebo šablony ARM. Pokud chcete určit správné ru/s, které se má nastavit, postupujte podle osvědčených postupů pro škálování zřízené propustnosti (RU/s).

Pokud existuje vysoké procento požadavků s omezenou rychlostí a existuje základní horký oddíl:

  • Z dlouhodobého hlediska z hlediska nejlepších nákladů a výkonu zvažte změnu klíče oddílu. Klíč oddílu není možné aktualizovat na místě, takže je potřeba migrovat data do nového kontejneru s jiným klíčem oddílu. Azure Cosmos DB pro tento účel podporuje nástroj pro migraci dat za provozu.
  • Krátkodobě můžete dočasně zvýšit počet RU/s, abyste umožnili větší propustnost horkého oddílu. Tato strategie se nedoporučuje jako dlouhodobá strategie, protože vede k příliš vysokému zřizování RU/s a vyšším nákladům.

Tip

Když zvýšíte propustnost, operace škálování se dokončí okamžitě nebo bude vyžadovat dokončení až 5 až 6 hodin v závislosti na počtu RU/s, na který chcete škálovat. Pokud chcete znát nejvyšší počet RU/s, který můžete nastavit bez aktivace asynchronní operace škálování (která vyžaduje, aby Azure Cosmos DB zř vynásobil více fyzických oddílů), vynásobte počet jedinečných ID rozsahu klíčů oddílů 10 0000 RU/s. Pokud máte například zřízeno 30 000 RU/s a 5 fyzických oddílů (přidělených 6 000 RU/s na fyzický oddíl), můžete během okamžité operace škálování zvýšit na 50 000 RU/s (10 000 RU/s na fyzický oddíl). Zvýšení na >50 000 RU/s by vyžadovalo asynchronní operaci škálování na více než 50 000 RU/s.

Krok 3: Určení, které požadavky vrací problémy 429

Jak prozkoumat požadavky s 429

Pomocí diagnostických protokolů Azure identifikujte, které požadavky vrací 429 a kolik SPOTŘEBOVANÝCH REZERVOVANÝCH PROSTŘEDKŮ. Tento ukázkový dotaz se agreguje na úrovni minut.

Důležité

Za povolení diagnostických protokolů se účtují samostatné poplatky za službu Log Analytics, která se účtuje na základě objemu ingestovaných dat. Doporučujeme zapnout diagnostické protokoly po omezenou dobu pro ladění a vypnout, pokud už nejsou potřeba. Podrobnosti najdete na stránce s cenami.

AzureDiagnostics
| where TimeGenerated >= ago(24h)
| where Category == "DataPlaneRequests"
| summarize throttledOperations = dcountif(activityId_g, statusCode_s == 429), totalOperations = dcount(activityId_g), totalConsumedRUPerMinute = sum(todouble(requestCharge_s)) by databaseName_s, collectionName_s, OperationName, requestResourceType_s, bin(TimeGenerated, 1min)
| extend averageRUPerOperation = 1.0 * totalConsumedRUPerMinute / totalOperations 
| extend fractionOf429s = 1.0 * throttledOperations / totalOperations
| order by fractionOf429s desc

Tento ukázkový výstup například ukazuje, že v každé minutě bylo rychlostně omezených 30 % požadavků na vytvoření dokumentu, kdy každý požadavek spotřebovává průměrně 17 rezervovaných měr. Požadavky s chybou 429 v diagnostických protokolech

Počet 429 u žádostí o vytvoření, nahrazení nebo upsert dokument
  • Ve výchozím nastavení se ve SQL API indexuje všechny vlastnosti. Vylaďte zásady indexování tak, aby indexovány pouze potřebné vlastnosti. Sníží se tím počet požadovaných jednotek žádostí pro operaci vytvoření dokumentu, což sníží pravděpodobnost, že se zobrazí 429, nebo vám umožní dosáhnout vyšších operací za sekundu pro stejné množství zřovaných RU/s.
429 u žádostí o dotazování na dokument
429 při spuštění uložených procedur
  • Uložené procedury jsou určené pro operace, které vyžadují transakce zápisu napříč hodnotou klíče oddílu. Pro velký počet operací čtení nebo dotazů se nedoporučuje používat uložené procedury. Pro nejlepší výkon by se tyto operace čtení nebo dotazování měly provádět na straně klienta pomocí Cosmos SDK.

Omezování rychlosti požadavků na metadata

Omezení rychlosti metadat může nastat při provádění velkého objemu operací s metadaty v databázích a kontejnerech. Mezi operace s metadaty patří:

  • Vytvoření, čtení, aktualizace nebo odstranění kontejneru nebo databáze
  • výpis databází nebo kontejnerů v účtu Cosmos
  • Dotaz na nabídky pro zobrazení aktuální zřízené propustnosti

Pro tyto operace je stanovený limit RU pro systém, takže zvýšení zřizovacích RU/s databáze nebo kontejneru nebude mít žádný dopad a nedoporučuje se. Viz omezení operací s metadaty.

Jak prošetřit

přejděte na Přehledy > > požadavky na Metadata systému podle stavového kódu. V případě potřeby vyfiltrujte na určitou databázi a kontejner.

tabulka žádosti o Metadata podle stavového kódu v Přehledy.

  • Pokud vaše aplikace potřebuje provádět operace s metadaty, zvažte implementaci zásad omezení rychlosti pro posílání těchto požadavků nižší rychlostí.

  • použijte statické Cosmos DB klientské instance. při inicializaci DocumentClient nebo CosmosClient načte sada Cosmos DB SDK metadata týkající se účtu, včetně informací o úrovni konzistence, databázích, kontejnerech, oddílech a nabídkách. Tato inicializace může využívat velké množství RU a měla by se provádět jenom zřídka. Použijte jednu instanci DocumentClient a využijte ji po celou dobu životnosti vaší aplikace.

  • Ukládání názvů databází a kontejnerů do mezipaměti. Načte názvy vašich databází a kontejnerů z konfigurace nebo je zapíše do mezipaměti při spuštění. Volání jako ReadDatabaseAsync/ReadDocumentCollectionAsync nebo CreateDatabaseQuery/CreateDocumentCollectionQuery budou mít za následek volání do služby, která spotřebuje z limitu RU rezervovaných systémem. Tyto operace by se měly provádět zřídka.

Omezení rychlosti kvůli přechodné chybě služby

Tato chyba 429 se vrátí, když v žádosti dojde k přechodné chybě služby. Zvýšení RU/s na databázi nebo kontejneru nebude mít žádný dopad a nedoporučuje se.

Opakujte požadavek. Pokud chyba trvá několik minut, zaregistrujte lístek podpory z Azure Portal.

Další kroky