Sdílet prostřednictvím

Diagnostika výjimek časového limitu požadavků sady .NET SDK služby Azure Cosmos DB a řešení souvisejících potíží

  • Článek

PLATÍ PRO: NoSQL

K chybě HTTP 408 dochází v případě, že sada SDK nedokáže požadavek dokončit před vypršením časového limitu.

Je důležité zajistit, aby návrh aplikace postupoval podle našeho průvodce návrhem odolných aplikací pomocí sad SDK služby Azure Cosmos DB, aby se zajistilo, že správně reaguje na různé síťové podmínky. Vaše aplikace by měla obsahovat logiku opakování v případě chyb vypršení časového limitu, ke kterým v distribuovaných systémech dochází běžně a jsou očekávané.

Při vyhodnocování případů chyb časového limitu:

  • Jaký je dopad měřený objemem ovlivněných operací v porovnání s úspěšnými operacemi? Nachází se v rámci smluv SLA služby?
  • Týká se latence nebo dostupnosti P99?
  • Týkají se selhání všech instancí aplikace, nebo pouze jejich podmnožiny? Pokud je problém omezený na podmnožinu instancí, jedná se obvykle o problém související s těmito instancemi.

Přizpůsobení časového limitu v sadě .NET SDK služby Azure Cosmos DB

Sada SDK má dvě různé alternativy k řízení časových limitů, z nichž každá má jiný rozsah.

Časové limity na úrovni požadavku

Konfigurace CosmosClientOptions.RequestTimeout (nebo ConnectionPolicy.RequestTimeout pro sadu SDK v2) umožňuje nastavit časový limit pro síťový požadavek po dokončení požadavku, který opustil sadu SDK a je v síti, dokud se neobdrží odpověď.

Konfigurace CosmosClientOptions.OpenTcpConnectionTimeout (nebo ConnectionPolicy.OpenTcpConnectionTimeout pro sadu SDK v2) umožňuje nastavit časový limit pro čas strávený otevřením počátečního připojení. Po otevření připojení budou následující požadavky používat připojení.

Operace spuštěná uživatelem může zahrnovat více síťových požadavků, například opakování. Tyto dvě konfigurace jsou pro každou žádost, nikoli kompletní pro operaci.

CancellationToken

Všechny asynchronní operace v sadě SDK mají volitelný parametr CancellationToken. Tento parametr CancellationToken se používá během celé operace ve všech síťových požadavcích a opakováních. Mezi síťovými požadavky je možné zkontrolovat token zrušení a v případě vypršení platnosti souvisejícího tokenu zrušit operaci. Token zrušení by se měl používat k definování přibližného očekávaného časového limitu v oboru rezervace.

Poznámka:

Parametr CancellationToken je mechanismus, kdy knihovna zkontroluje zrušení, když nezpůsobí neplatný stav. Operace se nemusí zrušit přesně v okamžiku vypršení časového limitu definovaného v tokenu zrušení. Místo toho se po vypršení časového limitu zruší v době, kdy je to bezpečné.

Postup při řešení potíží

Následující seznam obsahuje informace o známých příčinách a řešeních výjimek časového limitu požadavků.

CosmosOperationCanceledException

Tento typ výjimky je běžný v případě, že aplikace předává CancellationTokens operacím sady SDK. Sada SDK zkontroluje stav CancellationToken mezi opakovanými pokusy a pokud CancellationToken je zrušena, přeruší aktuální operaci s touto výjimkou.

Message / ToString() Výjimka také označuje stav vašeho CancellationToken průchodu Cancellation Token has expired: true a bude obsahovat také diagnostiku, která obsahuje kontext zrušení příslušných požadavků.

Tyto výjimky jsou bezpečné pro opakování a dají se považovat za časové limity z pohledu opakování.

Řešení

Ověřte nakonfigurovaný čas v počítači CancellationToken, ujistěte se, že je větší než váš RequestTimeout a CosmosClientOptions.OpenTcpConnectionTimeout (pokud používáte přímý režim). Pokud je dostupný čas v CancellationToken době kratší než nakonfigurované časové limity a u sady SDK dochází k přechodným problémům s připojením, sada SDK nebude moct opakovat a vyvolá CosmosOperationCanceledExceptionchybu .

Vysoké využití procesoru

Nejčastějším případem je vysoké využití procesoru. Pro zajištění optimální latence by využití procesoru mělo být přibližně 40 %. K monitorování maximálního (ne průměrného) využití procesoru použijte interval 10 sekund. Ke špičkám využití procesoru častěji dochází u dotazů napříč oddíly, kdy se pro jeden dotaz může navazovat více připojení.

Časové limity budou obsahovat diagnostiku, která obsahuje:

"systemHistory": [
{
"dateUtc": "2021-11-17T23:38:28.3115496Z",
"cpu": 16.731,
"memory": 9024120.000,
"threadInfo": {
"isThreadStarving": "False",
....
}

},
{
"dateUtc": "2021-11-17T23:38:28.3115496Z",
"cpu": 16.731,
"memory": 9024120.000,
"threadInfo": {
"isThreadStarving": "False",
....
}

},
...
]
  • cpu Pokud jsou hodnoty větší než 70 %, příčinou časového limitu je pravděpodobně vyčerpání procesoru. V takovém případě je řešením zjistit zdroj vysokého využití procesoru a snížit toto využití nebo škálovat počítač na větší velikost prostředků.
  • threadInfo/isThreadStarving Pokud uzly mají True hodnoty, příčinou je hladovění vlákna. V takovém případě je řešením zjistit zdroj nedostatku vláken (potenciálně uzamčených vláken) nebo škálovat počítač na větší velikost prostředků.
  • dateUtc Pokud čas mezi měřeními není přibližně 10 sekund, znamená to také kolize ve fondu vláken. CPU se měří jako nezávislá úloha, která je zařazena do fondu vláken každých 10 sekund. Pokud je doba mezi měřeními delší, znamená to, že asynchronní úlohy nemohou být zpracovány včas. Nejčastější scénáře jsou, když se v kódu aplikace provádí blokování volání přes asynchronní kód.

Řešení

Klientské aplikaci, která používá sadu SDK, by měla být vertikálně navýšena kapacita nebo by se měla škálovat na více instancí.

Nízká dostupnost soketů nebo portů

U klientů využívajících sadu .NET SDK, kteří běží v Azure, může dojít k vyčerpání portů Azure SNAT (PAT).

Řešení 1

Pokud používáte virtuální počítače Azure, postupujte podle průvodce vyčerpáním portů SNAT.

Řešení 2

Pokud používáte službu Aplikace Azure Service, postupujte podle průvodce odstraňováním chyb připojení a použijte diagnostiku služby App Service.

Řešení 3

Pokud používáte Azure Functions, ověřte, že sledujete doporučení Azure Functions k údržbě jednoúčelových nebo statických klientů pro všechny příslušné služby (včetně služby Azure Cosmos DB). Zkontrolujte limity služby na základě typu a velikosti hostování vaší aplikace Funkcí.

Řešení 4

Pokud používáte proxy server HTTP, ujistěte se, že podporuje počet připojení nakonfigurovaných v sadě SDK ConnectionPolicy. Jinak se setkáte s problémy s připojením.

Vytvoření více instancí klienta

Vytvoření více instancí klienta může vést k problémům s kolizí připojení a vypršením časového limitu. Diagnostika obsahuje dvě relevantní vlastnosti:

{
    "NumberOfClientsCreated":X,
    "NumberOfActiveClients":Y,
}

NumberOfClientsCreated sleduje, kolikrát CosmosClient byla vytvořena ve stejné doméně AppDomain, a NumberOfActiveClients sleduje aktivní klienty (nelikvidováno). Očekávání spočívá v tom, že pokud je dodržen jeden vzor, X odpovídá počtu účtů, se kterými aplikace pracuje, a to X je rovno Y.

Pokud X je větší než Y, znamená to, že aplikace vytváří a disponuje instance klienta. To může vést k kolizím připojení nebo kolizí procesoru.

Řešení

Postupujte podle tipů k výkonu a použijte jednu instanci CosmosClient pro každý účet v celém procesu. Vyhněte se vytváření a odstraňování klientů.

Klíč horkého oddílu

Služba Azure Cosmos DB rovnoměrně distribuuje celkovou zřízenou propustnost mezi fyzické oddíly. V případě horkého oddílu jeden nebo více klíčů logických oddílů na fyzickém oddílu využívá všechny jednotky žádostí za sekundu (RU/s) fyzického oddílu. Současně jsou nevyužité jednotky RU/s na ostatních fyzických oddílech. Jako příznak bude celková spotřeba RU/s menší než celková zřízená RU/s v databázi nebo kontejneru, ale u požadavků na klíč horkého logického oddílu se stále zobrazí omezování (429). Pomocí metriky Normalizovaná spotřeba RU zjistěte, jestli u úlohy dochází k horkému oddílu.

Řešení

Zvolte vhodný klíč oddílu, který rovnoměrně distribuuje svazek požadavků a úložiště. Zjistěte, jak změnit klíč oddílu.

Vysoký stupeň souběžnosti

Aplikace provádí vysokou úroveň souběžnosti, což může vést k kolizím v kanálu.

Řešení

Klientské aplikaci, která používá sadu SDK, by měla být vertikálně navýšena kapacita nebo by se měla škálovat na více instancí.

Velké požadavky nebo odpovědi

Velké požadavky nebo odpovědi můžou vést k blokování v kanálu a zhoršení kolize, a to i s relativně nízkým stupněm souběžnosti.

Řešení

Klientské aplikaci, která používá sadu SDK, by měla být vertikálně navýšena kapacita nebo by se měla škálovat na více instancí.

Míra selhání je v rámci smlouvy SLA služby Azure Cosmos DB.

Aplikace by měla být schopná zpracovat přechodné chyby a v případě potřeby to zkusit znovu. Žádné výjimky 408 se neopakují, protože při vytváření cest není možné zjistit, jestli služba vytvořila položku nebo ne. Opětovné odeslání stejné položky pro vytvoření způsobí konfliktní výjimku. Obchodní logika uživatelských aplikací může mít vlastní logiku pro zpracování konfliktů, což by přerušilo nejednoznačnost existující položky oproti konfliktu při pokusu o vytvoření.

Míra selhání porušuje smlouvu SLA služby Azure Cosmos DB

Obraťte se na podporu Azure.

Další kroky