Udostępnij za pośrednictwem

Diagnozowanie i rozwiązywanie problemów z wyjątkami limitu czasu żądania zestawu Java v4 SDK usługi Azure Cosmos DB

  • Artykuł

DOTYCZY: NoSQL

Błąd HTTP 408 występuje, jeśli zestaw SDK nie mógł wykonać żądania przed upłynięciem limitu czasu.

Kroki rozwiązywania problemów

Poniższa lista zawiera znane przyczyny i rozwiązania dotyczące wyjątków przekroczenia limitu czasu żądania.

Zasady limitu czasu end-to-end

Istnieją scenariusze, w których wystąpią błędy przekroczenia limitu czasu sieci 408 nawet wtedy, gdy wdrożono wszystkie rozwiązania wyprzedzania wymienione poniżej. Ogólną najlepszą praktyką w zakresie zmniejszenia opóźnienia końcowego, a także poprawy dostępności w tych scenariuszach jest zaimplementowanie zasad limitu czasu kompleksowego. Opóźnienie końcowe jest mniejsze dzięki szybszej awarii, a jednostki żądań i koszty obliczeń po stronie klienta są zmniejszane przez zatrzymywanie ponownych prób po przekroczeniu limitu czasu. Czas trwania limitu czasu można ustawić na .CosmosItemRequestOptions Opcje można następnie przekazać do dowolnego żądania wysłanego do usługi 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);

Istniejące problemy

Jeśli widzisz, że żądania są blokowane przez dłuższy czas lub częściej przekraczasz limit czasu, uaktualnij zestaw SDK języka Java w wersji 4 do najnowszej wersji. UWAGA: Zdecydowanie zalecamy używanie wersji 4.18.0 lub nowszej. Aby uzyskać więcej informacji, zapoznaj się z informacjami o wersji zestawu Java v4 SDK.

Wysoki poziom wykorzystania procesora

Wysokie użycie procesora jest najczęstszym przypadkiem. Aby uzyskać optymalne opóźnienie, użycie procesora powinno wynosić około 40%. Użyj interwału 10 sekund, aby monitorować maksymalne (a nie średnie) użycie procesora. Skoki użycia procesora są bardziej typowe w przypadku zapytań obejmujących wiele partycji, w których dla pojedynczego zapytania może być nawiązywanych wiele połączeń.

Rozwiązanie 2.

Aplikacja kliencka korzystająca z zestawu SDK powinna zostać przeskalowana w górę lub w poziomie.

Ograniczanie połączeń

Ograniczanie połączeń może wystąpić z powodu limitu połączenia na maszynie hosta lub wyczerpaniu portów SNAT (PAT).

Limit połączeń na maszynie hosta

Niektóre systemy Linux, takie jak Red Hat, mają górny limit całkowitej liczby otwartych plików. Gniazda w systemie Linux są implementowane jako pliki, więc ta liczba ogranicza łączną liczbę połączeń. Uruchom następujące polecenie.

ulimit -a

Rozwiązanie 2.

Maksymalna dozwolona liczba otwartych plików, które są identyfikowane jako "nofile", musi być co najmniej 10 000 lub więcej. Aby uzyskać więcej informacji, zobacz Porady dotyczące wydajności zestawu Java SDK usługi Azure Cosmos DB w wersji 4.

Dostępność gniazd lub portów może być niska

W przypadku uruchamiania na platformie Azure klienci korzystający z zestawu Java SDK mogą napotkać wyczerpanie portów SNAT (PAT) platformy Azure.

Rozwiązanie 1.

Jeśli korzystasz z maszyn wirtualnych platformy Azure, postępuj zgodnie z przewodnikiem wyczerpania portów SNAT.

Rozwiązanie 2.

Jeśli korzystasz z usługi aplikacja systemu Azure Service, postępuj zgodnie z przewodnikiem rozwiązywania problemów z błędami połączenia i skorzystaj z diagnostyki usługi App Service.

Rozwiązanie 3:

Jeśli korzystasz z usługi Azure Functions, sprawdź, czy obserwujesz zalecenie usługi Azure Functions dotyczące obsługi pojedynczych lub statycznych klientów dla wszystkich zaangażowanych usług (w tym usługi Azure Cosmos DB). Sprawdź limity usługi na podstawie typu i rozmiaru hostingu aplikacji funkcji.

Rozwiązanie 4:

Jeśli używasz serwera proxy HTTP, upewnij się, że może obsługiwać liczbę połączeń skonfigurowanych w zestawie SDK GatewayConnectionConfig. W przeciwnym razie będziesz napotykać problemy z połączeniem.

Tworzenie wielu wystąpień klienta

Tworzenie wielu wystąpień klientów może prowadzić do problemów z rywalizacją o połączenie i przekroczeniem limitu czasu.

Rozwiązanie 1.

Postępuj zgodnie z poradami dotyczącymi wydajności i używaj pojedynczego wystąpienia usługi CosmosClient w całej aplikacji.

Rozwiązanie 2.

Jeśli element Singleton CosmosClient nie jest możliwy w aplikacji, zalecamy używanie udostępniania połączeń między wieloma klientami usługi Azure Cosmos DB za pośrednictwem tego interfejsu API connectionSharingAcrossClientsEnabled(true) w usłudze CosmosClient. Jeśli masz wiele wystąpień klienta usługi Azure Cosmos DB w tym samym środowisku JVM współdziałającym z wieloma kontami usługi Azure Cosmos DB, włączenie tego ustawienia umożliwia udostępnianie połączeń w trybie bezpośrednim, jeśli jest to możliwe między wystąpieniami klienta usługi Azure Cosmos DB. Należy pamiętać, że podczas ustawiania tej opcji konfiguracja połączenia (np. konfiguracja limitu czasu gniazda, konfiguracja limitu czasu bezczynności) pierwszego wystąpienia klienta zostanie użyta dla wszystkich innych wystąpień klienta.

Klucz gorącej partycji

Usługa Azure Cosmos DB dystrybuuje ogólną aprowizowaną przepływność równomiernie między partycje fizyczne. Jeśli istnieje gorąca partycja, co najmniej jeden klucz partycji logicznej na partycji fizycznej zużywa wszystkie jednostki żądań partycji fizycznej na sekundę (RU/s). Jednocześnie liczba jednostek żądań na sekundę na innych partycjach fizycznych jest nieużywana. Jako objaw łączna liczba jednostek RU/s zużytych będzie mniejsza niż ogólna aprowizowana jednostka RU/s w bazie danych lub kontenerze, ale nadal zobaczysz ograniczanie przepustowości (429s) na żądaniach względem gorącego klucza partycji logicznej. Użyj metryki Znormalizowane użycie jednostek RU, aby sprawdzić, czy obciążenie napotyka gorącą partycję.

Rozwiązanie 2.

Wybierz dobry klucz partycji, który równomiernie dystrybuuje wolumin żądań i magazyn. Dowiedz się, jak zmienić klucz partycji.

Wysoki stopień współbieżności

Aplikacja wykonuje wysoki poziom współbieżności, co może prowadzić do rywalizacji w kanale.

Rozwiązanie 2.

Aplikacja kliencka korzystająca z zestawu SDK powinna zostać przeskalowana w górę lub w poziomie.

Duże żądania lub odpowiedzi

Duże żądania lub odpowiedzi mogą prowadzić do blokowania nagłówka w kanale i zaostrzenia rywalizacji, nawet przy stosunkowo niskim stopniu współbieżności.

Rozwiązanie 2.

Aplikacja kliencka korzystająca z zestawu SDK powinna zostać przeskalowana w górę lub w poziomie.

Współczynnik niepowodzeń znajduje się w umowie SLA usługi Azure Cosmos DB

Aplikacja powinna mieć możliwość obsługi przejściowych błędów i ponawiania próby w razie potrzeby. Żadne wyjątki 408 nie są ponawiane, ponieważ na ścieżkach tworzenia nie można wiedzieć, czy usługa utworzyła element, czy nie. Ponowne wysłanie tego samego elementu do utworzenia spowoduje wyjątek powodujący konflikt. Logika biznesowa aplikacji użytkownika może mieć niestandardową logikę do obsługi konfliktów, co mogłoby spowodować przerwanie z niejednoznaczności istniejącego elementu w porównaniu z konfliktem z próby utworzenia.

Współczynnik niepowodzeń narusza umowę SLA usługi Azure Cosmos DB

Skontaktuj się z pomocą techniczną platformy Azure.

Następne kroki