Udostępnij za pośrednictwem


Diagnozowanie i rozwiązywanie problemów z wyjątkami limitu czasu żądań zestawu SDK platformy .NET dla usługi Azure Cosmos DB dla platformy NoSQL

Błąd HTTP 408 występuje, jeśli zestaw SDK (Software Development Kit) nie mógł ukończyć żądania przed upływem limitu czasu.

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

Podczas oceny przypadku błędów związanych z przekroczeniem limitu czasu należy wziąć pod uwagę następujące działania:

  • Zmierz efekt w ilości operacji, których dotyczy problem, w porównaniu z powodzeniem operacji.
  • Ustal, czy efekt mieści się w progach zdefiniowanych w umowie dotyczącej poziomu usług.
  • Oceń, jak ma to wpływ na opóźnienie lub dostępność P99.
  • Określ, czy awaria ma wpływ na wszystkie wystąpienia aplikacji, czy tylko na część.

Dostosuj limit czasu w SDK platformy .NET usługi Azure Cosmos DB for NoSQL

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

Limit czasu poziomu żądania

Konfiguracja ConnectionPolicy.RequestTimeout (lub ConnectionPolicy.RequestTimeout dla SDK w wersji 2) umożliwia ustawienie limitu czasowego dla żądania sieciowego po jego opuszczeniu przez SDK i znajdowaniu się w sieci, aż do momentu odebrania odpowiedzi.

Konfiguracja ConnectionPolicy.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 używają 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.

Token anulowania (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. Pomiędzy żądaniami sieciowymi można sprawdzić token anulowania i anulować operację, jeśli powiązany token wygasł. Token anulowania powinien służyć do definiowania przybliżonego oczekiwanego okresu czasu dla zakresu operacji.

Uwaga / Notatka

Parametr CancellationToken jest mechanizmem, w którym biblioteka sprawdza, czy anulowanie może spowodować nieprawidłowy stan. Operacja może nie zostać anulowana dokładnie w momencie, gdy upływa czas zdefiniowany 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 wyjątków przekroczenia limitu czasu żądania.

CosmosOperationCanceledException (Wyjątek anulowania operacji w Cosmos)

Ten typ wyjątku często występuje, gdy aplikacja przekazuje CancellationTokens do operacji w SDK. Zestaw SDK sprawdza stan CancellationToken pomiędzy ponownymi próbami, a jeśli CancellationToken zostanie anulowany, przerywa bieżącą operację, powodując wystąpienie tego wyjątku.

Message / ToString() Wyjątek wskazuje również stan CancellationToken przez Cancellation Token has expired: true i zawiera Diagnostics, które zawierają kontekst anulowania dla zaangażowanych żądań.

Te wyjątki można bezpiecznie ponawiać i mogą być traktowane jako [wyjątki przekroczenia limitu czasu](koncepcyjnie-resilient-sdk-applications.md#time-outs-and-connectivity-related-failures-http-408503) z perspektywy ponowienia.

Rozwiązanie

Sprawdź skonfigurowany czas w pliku CancellationToken. Następnie upewnij się, że jest on większy niż limit czasu żądania oraz CosmosClientOptions.OpenTcpConnectionTimeout właściwość (jeśli korzystasz z trybu bezpośredniego). Jeśli dostępny czas w parametrze CancellationToken jest krótszy niż skonfigurowany limit czasu, oraz zestaw SDK napotyka [przejściowe problemy z łącznością](koncepcyjnie odporne na błędy zestawu SDK-applications.md#times-and-connectivity-related-failures-http-408503), nie może ponowić próby i zgłasza wyjątek 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 10 sekund jako interwału, aby monitorować maksymalne (nie średnie) użycie procesora CPU. 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ń.

Przekroczenie czasu zawiera Diagnostics, które 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 procent, wyczerpanie procesora CPU prawdopodobnie spowodowało przekroczenie limitu czasu. W takim przypadku rozwiązaniem jest zbadanie źródła wysokiego wykorzystania procesora CPU i zmniejszenie go lub skalowanie maszyny do większego rozmiaru zasobów.
  • Jeśli węzły threadInfo/isThreadStarving mają True wartości, przyczyną jest głodzenie wątku. W takim przypadku rozwiązaniem jest zbadanie przyczyn przyblokowania wątków (potencjalnie zablokowanych wątków) lub skalowanie maszyn do większych 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. CPU jest mierzony jako niezależne zadanie, które jest umieszczane w kolejce w puli wątków co 10 sekund. Jeśli czas między pomiarami jest dłuższy, oznaczałoby to, że zadania asynchroniczne nie mogą być przetwarzane w odpowiednim czasie. Ten scenariusz występuje często podczas blokowania wywołań za pośrednictwem kodu asynchronicznego w kodzie aplikacji.

Rozwiązanie

Aplikacja kliencka korzystająca z zestawu SDK powinna zostać przeskalowana wertykalnie lub horyzontalnie.

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

Gdy rozwiązanie jest uruchomione na platformie Azure, klienci korzystający z zestawu .NET SDK mogą napotkać wyczerpanie portów translacji adresów sieciowych (SNAT) źródła 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 Azure App Service, postępuj zgodnie z przewodnikiem rozwiązywania problemów z błędami połączenia i wykorzystaj diagnostykę usługi App Service.

Rozwiązanie 3

Jeśli korzystasz z usługi Azure Functions, sprawdź, czy korzystasz z rekomendacji usługi Azure Functions dotyczącej obsługi pojedynczych lub statycznych klientów dla wszystkich zaangażowanych usług (w tym usługi Azure Cosmos DB for NoSQL). 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 występują problemy z połączeniem.

Tworzenie wielu wystąpień klienta

Tworzenie wielu instancji klientów może prowadzić do problemów z konfliktem połączeń i czasem oczekiwania. 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 zastosowany wzorzec singleton, X będzie odpowiadać liczbie kont, z którymi działa aplikacja, a X będzie równe Y.

Jeśli X jest większe niż Y, oznacza to, że aplikacja tworzy i usuwa wystąpienia klienta. Ten scenariusz może 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 usuwania klientów.

Gorący klucz partycji

Usługa Azure Cosmos DB for NoSQL dystrybuuje ogólną aprowizowaną przepływność równomiernie między partycjami fizycznymi. Jeśli istnieje przegrzana partycja, co najmniej jeden klucz partycji logicznej na partycji fizycznej zużywa wszystkie jednostki żądań na sekundę (RU/s) tej partycji fizycznej. Jednocześnie RU/s na innych partycjach fizycznych są niewykorzystywane. Jako objaw, łączna liczba zużywanych jednostek RU/s jest mniejsza niż ogólna liczba przydzielonych jednostek RU/s w bazie danych lub kontenerze, ale występuje ograniczanie przepustowości (błędy 429) na żądaniach dotyczących intensywnie wykorzystywanego klucza partycji logicznej. Normalized RU Consumption Użyj metryki, 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 przetwarzania równoczesnego, co może prowadzić do konfliktu na kanale.

Rozwiązanie

Aplikacja kliencka korzystająca z zestawu SDK powinna zostać przeskalowana wertykalnie lub horyzontalnie.

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 wertykalnie lub horyzontalnie.

Wskaźnik awarii mieści się w zakresie przewidzianym przez umowę dotyczącą poziomu usług (SLA) Azure Cosmos DB for NoSQL.

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. Wysłanie tego samego elementu ponownie dla create powoduje konfliktowy wyjątek. Logika biznesowa aplikacji użytkownika może zawierać niestandardowe zasady obsługi konfliktów, co pozwala rozwiązać niejednoznaczności między istniejącym elementem a konfliktem wynikającym z ponownej próby utworzenia.

Współczynnik niepowodzeń narusza zasady SLA dla Azure Cosmos DB for NoSQL

Skontaktuj się z Wsparciem Azure.