Uwaga
Dostęp do tej strony wymaga autoryzacji. Może spróbować zalogować się lub zmienić katalogi.
Dostęp do tej strony wymaga autoryzacji. Możesz spróbować zmienić katalogi.
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ło10
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 co10
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.
Treści powiązane
- Diagnozowanie i rozwiązywanie problemów podczas korzystania z zestawu .NET SDK usługi Azure Cosmos DB for NoSQL.
- Dowiedz się więcej o wytycznych dotyczących wydajności platformy .NET w wersji 3 i .NET w wersji 2.