Udostępnij za pośrednictwem

Diagnozowanie i rozwiązywanie problemów z wyjątkami limitu czasu żądania zestawu .NET 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.

Ważne jest, aby upewnić się, że projekt aplikacji jest zgodnie z naszym przewodnikiem dotyczącym projektowania odpornych aplikacji przy użyciu zestawów SDK usługi Azure Cosmos DB, aby upewnić się, że prawidłowo reaguje na różne warunki sieciowe. Aplikacja powinna mieć zaimplementowane ponawianie prób w przypadku błędów przekroczenia limitu czasu, ponieważ zwykle są one oczekiwane w systemie rozproszonym.

Podczas oceniania przypadku błędów przekroczenia limitu czasu:

  • Jaki jest wpływ mierzony w ilości operacji, których dotyczy problem, w porównaniu z operacjami, które zakończyły się powodzeniem? Czy jest ona w ramach umów SLA usługi?
  • Czy ma to wpływ na opóźnienie /dostępność P99?
  • Czy awarie wpływają na wszystkie wystąpienia aplikacji, czy tylko na ich podzestaw? Gdy problem zostanie zredukowany do podzestawu wystąpień, często jest to problem związany z tymi wystąpieniami.

Dostosowywanie limitu czasu zestawu SDK platformy .NET usługi Azure Cosmos DB

Zestaw SDK ma dwie odrębne alternatywy dla kontrolowania limitów czasu, z których każdy ma inny zakres.

Limity czasu na poziomie żądania

Konfiguracja CosmosClientOptions.RequestTimeout (lub ConnectionPolicy.RequestTimeout dla zestawu SDK w wersji 2) umożliwia ustawienie limitu czasu dla żądania sieciowego po opuszczeniu zestawu SDK i w sieci do momentu odebrania odpowiedzi.

Konfiguracja CosmosClientOptions.OpenTcpConnectionTimeout (lub ConnectionPolicy.OpenTcpConnectionTimeout dla zestawu SDK w wersji 2) umożliwia ustawienie limitu czasu dla czasu spędzonego na otwarciu połączenia początkowego. Po otwarciu połączenia kolejne żądania będą używać połączenia.

Operacja uruchomiona przez użytkownika może obejmować wiele żądań sieciowych, na przykład ponawianie prób. Te dwie konfiguracje są na żądanie, a nie kompleksowe dla operacji.

CancellationToken

Wszystkie operacje asynchroniczne w zestawie SDK mają opcjonalny parametr CancellationToken. Ten parametr CancellationToken jest używany w całej operacji we wszystkich żądaniach sieciowych i ponownych próbach. Między żądaniami sieciowym token anulowania może zostać sprawdzony, a operacja anulowana, jeśli powiązany token wygasł. Token anulowania powinien być używany do definiowania przybliżonego oczekiwanego limitu czasu w zakresie operacji.

Uwaga

Parametr CancellationToken jest mechanizmem, w którym biblioteka sprawdzi anulowanie, gdy nie spowoduje nieprawidłowego stanu. Operacja może nie zostać anulowana dokładnie po upłynięciu czasu zdefiniowanego w anulowaniu. Zamiast tego po upłynięciu czasu zostanie anulowana, gdy będzie to bezpieczne.

Kroki rozwiązywania problemów

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

CosmosOperationCanceledException

Ten typ wyjątku często występuje, gdy aplikacja przekazuje elementy CancellationToken do operacji zestawu SDK. Zestaw SDK sprawdza stan ponownych CancellationToken prób między próbami, a jeśli CancellationToken element zostanie anulowany, przerwa bieżącą operację z tym wyjątkiem.

MessageToString() / Wyjątek będzie również wskazywać stan elementu CancellationToken za pośrednictwem Cancellation Token has expired: true i będzie również zawierać diagnostykę, która zawiera kontekst anulowania dla zaangażowanych żądań.

Te wyjątki są bezpieczne do ponawiania próby i mogą być traktowane jako przekroczenia limitu czasu z perspektywy ponawiania prób.

Rozwiązanie

Sprawdź skonfigurowany czas w elemecie CancellationToken, upewnij się, że jest on większy niż parametr RequestTimeout i CosmosClientOptions.OpenTcpConnectionTimeout (jeśli używasz trybu bezpośredniego). Jeśli dostępny czas w obiekcie CancellationToken jest krótszy niż skonfigurowane limity czasu, a zestaw SDK napotyka przejściowe problemy z łącznością, zestaw SDK nie będzie mógł ponowić próby i zgłosi błąd CosmosOperationCanceledException.

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ń.

Limity czasu będą zawierać diagnostykę, która zawiera:

"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 Jeśli wartości są ponad 70%, limit czasu prawdopodobnie będzie spowodowany wyczerpaniem procesora CPU. W takim przypadku rozwiązaniem jest zbadanie źródła dużego użycia procesora CPU i zmniejszenie go lub przeskalowanie maszyny do większego rozmiaru zasobów.
  • Jeśli węzły threadInfo/isThreadStarving mają True wartości, przyczyną jest głodowanie wątku. W takim przypadku rozwiązaniem jest zbadanie źródła przetrzymania wątku (potencjalnie zablokowane wątki) lub przeskalowanie maszyny do większego rozmiaru zasobów.
  • dateUtc Jeśli czas między pomiarami nie wynosi około 10 sekund, oznacza to również rywalizację w puli wątków. Pomiar procesora CPU to niezależne zadanie umieszczane w kolejce w puli wątków co 10 sekund. Jeśli czas między pomiarami byłby dłuższy, oznaczałoby to, że zadania asynchroniczne nie mogą być przetwarzane na czas. Najczęściej dochodzi do tego, gdy są wykonywane wywołania blokujące za pośrednictwem kodu asynchronicznego w kodzie aplikacji.

Rozwiązanie

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

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

Podczas uruchamiania na platformie Azure klienci korzystający z zestawu SDK platformy .NET mogą napotkać wyczerpanie portów usługi Azure SNAT (PAT).

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 ConnectionPolicy. 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. Diagnostyka zawiera dwie istotne właściwości:

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

NumberOfClientsCreated śledzi liczbę utworzenia obiektu CosmosClient w obrębie tej samej domeny aplikacji i NumberOfActiveClients śledzi aktywnych klientów (nie są usuwane). Oczekuje się, że jeśli zostanie uwzględniony X wzorzec pojedynczego, będzie odpowiadać liczbie kont, z którymi działa aplikacja, a to X jest równe Y.

Jeśli X wartość jest większa niż Y, oznacza to, że aplikacja tworzy i dysponuje wystąpienia klienta. Może to prowadzić do rywalizacji o połączenie i/lub rywalizację o procesor.

Rozwiązanie

Postępuj zgodnie z poradami dotyczącymi wydajności i używaj pojedynczego wystąpienia usługi CosmosClient na konto w całym procesie. Unikaj tworzenia i rozpraszania klientów.

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

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

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

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