Diagnostika výjimek časového limitu požadavků sady Java v4 SDK služby Azure Cosmos DB a řešení souvisejících potíží
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.
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ů.
Zásady časového limitu koncového časového limitu
Existují scénáře, kdy dojde k chybám časového limitu sítě 408 i v případě, že jsou implementovaná všechna níže uvedená řešení. Obecným osvědčeným postupem pro snížení koncové latence a zvýšení dostupnosti v těchto scénářích je implementace komplexních zásad časového limitu. Koncová latence se snižuje tím, že selhává rychleji a jednotky žádostí a náklady na výpočetní prostředky na straně klienta se snižují zastavením opakování po vypršení časového limitu. Časový limit lze nastavit na CosmosItemRequestOptionshodnotu . Možnosti se pak dají předat libovolnému požadavku odeslanému do služby Azure Cosmos DB:
CosmosEndToEndOperationLatencyPolicyConfig endToEndOperationLatencyPolicyConfig = new CosmosEndToEndOperationLatencyPolicyConfigBuilder(Duration.ofSeconds(1)).build();
CosmosItemRequestOptions options = new CosmosItemRequestOptions();
options.setCosmosEndToEndOperationLatencyPolicyConfig(endToEndOperationLatencyPolicyConfig);
container.readItem("id", new PartitionKey("pk"), options, TestObject.class);
Existující problémy
Pokud dochází k zablokování požadavků po delší dobu nebo k častějšímu časového limitu, upgradujte sadu Java SDK verze 4 na nejnovější verzi. POZNÁMKA: Důrazně doporučujeme použít verzi 4.18.0 a vyšší. Další podrobnosti najdete v poznámkách k verzi sady Java v4 SDK.
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í.
Ř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í.
Omezování připojení
K omezování připojení může dojít z důvodu limitu připojení na hostitelském počítači nebo vyčerpání portů AZURE SNAT (PAT).
Omezení připojení na hostitelském počítači
Některé systémy Linux, například Red Hat, mají horní limit celkového počtu otevřených souborů. Sokety v Linuxu se implementují jako soubory, takže toto číslo omezuje také celkový počet připojení. Spusťte následující příkaz:
ulimit -a
Řešení:
Maximální povolený počet povolených otevřených souborů, které jsou označené jako "nofile", musí být alespoň 10 000 nebo více. Další informace najdete v tipech k výkonu sady Java SDK služby Azure Cosmos DB verze 4.
Nízká dostupnost soketů nebo portů
Při spuštění v Azure můžou klienti, kteří používají sadu Java SDK, dojít k vyčerpání portů Azure SNAT (PAT).
1. řešení:
Pokud používáte virtuální počítače Azure, postupujte podle průvodce vyčerpáním portů SNAT.
2. řešení:
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 GatewayConnectionConfig. 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.
1. řešení:
Postupujte podle tipů k výkonu a použijte jednu instanci CosmosClient v celé aplikaci.
2. řešení:
Pokud v aplikaci není možné mít singleton CosmosClient, doporučujeme použít sdílení připojení mezi více klienty Azure Cosmos DB prostřednictvím tohoto rozhraní API connectionSharingAcrossClientsEnabled(true) ve službě CosmosClient.
Pokud máte ve stejném prostředí JVM více instancí klienta Služby Azure Cosmos DB, které pracují s více účty Azure Cosmos DB, povolte to sdílení připojení v přímém režimu, pokud je to možné mezi instancemi klienta služby Azure Cosmos DB. Při nastavování této možnosti se konfigurace připojení (např. konfigurace časového limitu soketu, konfigurace časového limitu nečinnosti) prvního instance klienta použije pro všechny ostatní instance klienta.
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
- Diagnostika a řešení potíží při používání sady Azure Cosmos DB Java SDK v4
- Přečtěte si informace o pokynech k výkonu pro Javu v4.