Share via

Diagnozowanie i rozwiązywanie problemów z wyjątkami zbyt dużej szybkości żądań usługi Azure Cosmos DB (429)

  • Artykuł

DOTYCZY: NoSQL

Ten artykuł zawiera znane przyczyny i rozwiązania różnych błędów kodu stanu 429 dla interfejsu API dla noSQL. Jeśli używasz interfejsu API dla bazy danych MongoDB, zobacz artykuł Rozwiązywanie typowych problemów z interfejsem API dla bazy danych MongoDB , aby uzyskać informacje na temat debugowania kodu stanu 16500.

Wyjątek "Zbyt duża liczba żądań", znany również jako kod błędu 429, wskazuje, że żądania względem usługi Azure Cosmos DB są ograniczone.

W przypadku korzystania z aprowizowanej przepływności należy ustawić przepływność mierzoną w jednostkach żądań na sekundę (RU/s) wymaganych dla obciążenia. Operacje bazy danych względem usługi, takie jak odczyty, zapisy i zapytania, zużywają pewną liczbę jednostek żądania (RU). Dowiedz się więcej o jednostkach żądań.

Jeśli w danej sekundzie operacje zużywają więcej niż aprowizowane jednostki żądania, usługa Azure Cosmos DB zwróci wyjątek 429. W każdej sekundzie liczba jednostek żądań dostępnych do użycia jest resetowana.

Przed podjęciem akcji w celu zmiany jednostek RU/s należy zrozumieć główną przyczynę ograniczania szybkości i rozwiązać podstawowy problem.

Porada

Wskazówki zawarte w tym artykule dotyczą baz danych i kontenerów korzystających z aprowizowanej przepływności — zarówno automatycznego skalowania, jak i przepływności ręcznej.

Istnieją różne komunikaty o błędach, które odpowiadają różnym typom wyjątków 429:

Szybkość żądań jest duża

Jest to najbardziej typowy scenariusz. Występuje, gdy jednostki żądania używane przez operacje na danych przekraczają aprowizowaną liczbę jednostek RU/s. Jeśli używasz przepływności ręcznej, dzieje się tak, gdy zużywasz więcej jednostek RU/s niż aprowizowana ręcznie przepływność. Jeśli używasz skalowania automatycznego, dzieje się tak, gdy zużyto więcej niż maksymalna aprowizowana wartość RU/s. Jeśli na przykład masz zasób aprowizowany z ręczną przepływnością 400 RU/s, zobaczysz 429, gdy używasz więcej niż 400 jednostek żądania w ciągu jednej sekundy. Jeśli masz zasób aprowizowany przy użyciu maksymalnej wartości RU/s autoskalowania 4000 RU/s (skaluje się między 400 RU/s - 4000 RU/s), zobaczysz 429 odpowiedzi, gdy używasz więcej niż 4000 jednostek żądania w ciągu jednej sekundy.

Porada

Opłaty za wszystkie operacje są naliczane na podstawie liczby używanych zasobów. Te opłaty są mierzone w jednostkach żądań. Te opłaty obejmują żądania, które nie zostały ukończone pomyślnie z powodu błędów aplikacji, takich jak 400, 412, 449itp. Patrząc na ograniczanie przepustowości lub użycie, warto sprawdzić, czy jakiś wzorzec uległ zmianie w użyciu, co spowodowałoby wzrost tych operacji. W szczególności sprawdź tagi 412 lub 449 (rzeczywisty konflikt).

Aby uzyskać więcej informacji na temat aprowizowanej przepływności, zobacz aprowizowanie przepływności w usłudze Azure Cosmos DB.

Krok 1. Sprawdzanie metryk w celu określenia wartości procentowej żądań z błędem 429

Wyświetlanie komunikatów o błędach 429 nie musi oznaczać problemu z bazą danych lub kontenerem. Niewielka wartość procentowa 429 odpowiedzi jest normalna niezależnie od tego, czy używasz przepływności ręcznej, czy automatycznej skalowania, i jest to znak, że maksymalizujesz aprowizowaną jednostkę RU/s.

Jak badać

Ustal, jaki procent żądań do bazy danych lub kontenera spowodował 429 odpowiedzi, w porównaniu z ogólną liczbą żądań zakończonych powodzeniem. Na koncie usługi Azure Cosmos DB przejdź do pozycji InsightsRequestsTotal Requests by Status Code (Łączna liczba żądań szczegółowych >według> kodu stanu). Filtruj do określonej bazy danych i kontenera.

Domyślnie zestawy SDK klienta usługi Azure Cosmos DB i narzędzia do importowania danych, takie jak Azure Data Factory i biblioteka funkcji wykonawczej operacji zbiorczych, automatycznie ponawiają żądania na 429s. Są one zwykle ponawiane do dziewięciu razy. W związku z tym, chociaż w metrykach może być wyświetlanych 429 odpowiedzi, te błędy mogą nawet nie zostać zwrócone do aplikacji.

Wykres Total Requests by Status Code (Łączna liczba żądań według kodu stanu), który pokazuje liczbę żądań 429 i 2xx.

Ogólnie rzecz biorąc, w przypadku obciążenia produkcyjnego, jeśli widzisz od 1 do 5% żądań z 429 odpowiedziami, a opóźnienie końcowe jest akceptowalne, jest to znak dobrej kondycji, że ru/s są w pełni wykorzystywane. Nie jest wymagana żadna akcja. W przeciwnym razie przejdź do następnych kroków rozwiązywania problemów.

Ważne

Ten zakres 1–5% zakłada, że partycje konta są równomiernie dystrybuowane. Jeśli partycje nie są równomiernie rozproszone, partycja problemu może zwrócić dużą liczbę błędów 429, podczas gdy ogólna szybkość może być niska.

Jeśli używasz autoskalowania, możesz zobaczyć 429 odpowiedzi w bazie danych lub kontenerze, nawet jeśli liczba jednostek RU/s nie została przeskalowana do maksymalnej liczby jednostek RU/s. Aby uzyskać wyjaśnienie, zobacz sekcję Częstotliwość żądań jest duża z autoskalowaniem .

Pojawia się jedno z typowych pytań: "Dlaczego widzę 429 odpowiedzi w metrykach usługi Azure Monitor, ale nie ma ich we własnym monitorowaniu aplikacji?" Jeśli metryki usługi Azure Monitor pokazują, że masz 429 odpowiedzi, ale nie widać ich we własnej aplikacji, jest to spowodowane tym, że domyślnie zestawy SDK automatically retried internally on the 429 responses klienta usługi Azure Cosmos DB i żądanie zakończyło się powodzeniem w kolejnych ponownych próbach. W związku z tym kod stanu 429 nie jest zwracany do aplikacji. W takich przypadkach ogólna szybkość odpowiedzi wynosząca 429 jest zwykle minimalna i można je bezpiecznie zignorować, zakładając, że ogólna szybkość wynosi od 1 do 5% i całkowite opóźnienie jest akceptowalna dla aplikacji.

Krok 2. Określanie, czy istnieje gorąca partycja

Gorąca partycja pojawia się, gdy jeden lub kilka kluczy partycji logicznych zużywa nieproporcjonalną ilość całkowitej liczby jednostek RU/s z powodu większego woluminu żądania. Może to być spowodowane przez projekt klucza partycji, który nie dystrybuuje równomiernie żądań. Powoduje to kierowanie wielu żądań do małego podzbioru partycji logicznych (co oznacza fizyczne) partycji, które stają się "gorące". Ponieważ wszystkie dane partycji logicznej znajdują się na jednej partycji fizycznej, a łączna liczba jednostek RU/s jest równomiernie rozłożona między partycje fizyczne, gorąca partycja może prowadzić do 429 odpowiedzi i nieefektywnego wykorzystania przepływności.

Oto kilka przykładów strategii partycjonowania, które prowadzą do gorących partycji:

  • Masz kontener przechowując dane urządzeń IoT dla obciążenia z dużym obciążeniem zapisu podzielonym na partycje według .date Wszystkie dane dla jednej daty będą znajdować się na tej samej partycji logicznej i fizycznej. Ponieważ wszystkie zapisane dane każdego dnia mają taką samą datę, co dzień spowoduje to powstanie gorącej partycji.
    • Zamiast tego w tym scenariuszu klucz partycji, taki jak id (identyfikator GUID lub identyfikator urządzenia), albo syntetyczny klucz partycji łączący id i date daje większą kardynalność wartości i lepszą dystrybucję woluminu żądania.
  • Masz scenariusz z wieloma dzierżawami z kontenerem podzielonym na partycje według .tenantId Jeśli jedna dzierżawa jest o wiele bardziej aktywna niż pozostałe, powoduje to gorącą partycję. Jeśli na przykład największa dzierżawa ma 100 000 użytkowników, ale większość dzierżaw ma mniej niż 10 użytkowników, podczas partycjonowania tenantIDprzez usługę będziesz mieć gorącą partycję.
    • W tym poprzednim scenariuszu rozważ utworzenie dedykowanego kontenera dla największej dzierżawy podzielonej na partycje według bardziej szczegółowej właściwości, takiej jak UserId.

Jak zidentyfikować gorącą partycję

Aby sprawdzić, czy istnieje gorąca partycja, przejdź do pozycji Szczegółowe informacje>>O znormalizowanym zużyciu jednostek RU (%) według identyfikatora PartitionKeyRangeID. Filtruj do określonej bazy danych i kontenera.

Każda partycja PartitionKeyRangeId mapuje na jedną partycję fizyczną. Jeśli istnieje jeden identyfikator PartitionKeyRangeId, który ma znacznie wyższe znormalizowane użycie jednostek RU niż inne (na przykład jeden jest stale w 100%, ale inne są w 30% lub mniej), może to być oznaką gorącej partycji. Dowiedz się więcej o metryce Znormalizowane użycie jednostek RU.

Znormalizowane użycie jednostek RU według wykresu PartitionKeyRangeId z gorącą partycją.

Aby sprawdzić, które klucze partycji logicznej zużywają najwięcej jednostek RU/s, użyj dzienników diagnostycznych platformy Azure. To przykładowe zapytanie sumuje łączną liczbę jednostek żądania wykorzystanych na sekundę dla każdego klucza partycji logicznej.

Ważne

Włączenie dzienników diagnostycznych powoduje naliczanie oddzielnej opłaty za usługę Log Analytics, która jest rozliczana na podstawie ilości pozyskanych danych. Zaleca się włączenie dzienników diagnostycznych przez ograniczony czas na debugowanie i wyłączenie, gdy nie jest już wymagane. Aby uzyskać szczegółowe informacje, zobacz stronę cennika .

 CDBPartitionKeyRUConsumption
 | where TimeGenerated >= ago(24hour)
 | where CollectionName == "CollectionName"
 | where isnotempty(PartitionKey)
 // Sum total request units consumed by logical partition key for each second
 | summarize sum(RequestCharge) by PartitionKey, OperationName, bin(TimeGenerated, 1s)
 | order by sum_RequestCharge desc

Te przykładowe dane wyjściowe pokazują, że w określonej minucie klucz partycji logicznej o wartości "Contoso" zużywał około 12 000 RU/s, podczas gdy klucz partycji logicznej o wartości "Fabrikam" zużywał mniej niż 600 RU/s. Jeśli ten wzorzec był spójny w okresie, w którym wystąpiło ograniczanie szybkości, oznacza to gorącą partycję.

Klucze partycji logicznej zużywające najwięcej jednostek żądania na sekundę.

Porada

W każdym obciążeniu wystąpią naturalne różnice w woluminie żądań w partycjach logicznych. Należy określić, czy gorąca partycja jest spowodowana przez podstawową niesymetryczność ze względu na wybór klucza partycji (co może wymagać zmiany klucza) lub tymczasowy wzrost z powodu naturalnego odchylenia we wzorcach obciążenia.

Zapoznaj się ze wskazówkami dotyczącymi wyboru dobrego klucza partycji.

Jeśli istnieje duża liczba żądań z ograniczoną szybkością i brak gorącej partycji:

Jeśli istnieje duża liczba żądań z ograniczoną szybkością i istnieje podstawowa gorąca partycja:

  • Długoterminowe, aby uzyskać najlepszy koszt i wydajność, rozważ zmianę klucza partycji. Nie można zaktualizować klucza partycji, dlatego wymaga to migracji danych do nowego kontenera z innym kluczem partycji. Usługa Azure Cosmos DB obsługuje w tym celu narzędzie do migracji danych na żywo.
  • Krótkoterminowo można tymczasowo zwiększyć ogólną liczbę jednostek RU/s zasobu, aby umożliwić większą przepływność gorącej partycji. Nie jest to zalecane jako długoterminowa strategia, ponieważ prowadzi do nadmiernej aprowizacji jednostek RU/s i wyższych kosztów.
  • Krótkoterminowo można użyć redystrybucji przepływności między funkcjami partycji (wersja zapoznawcza), aby przypisać więcej jednostek RU/s do partycji fizycznej, która jest gorąca. Jest to zalecane tylko wtedy, gdy gorąca partycja fizyczna jest przewidywalna i spójna.

Porada

Po zwiększeniu przepływności operacja skalowania w górę zostanie ukończona natychmiast lub będzie wymagać ukończenia do 5–6 godzin, w zależności od liczby jednostek RU/s, do których chcesz przeprowadzić skalowanie w górę. Jeśli chcesz znać największą liczbę jednostek RU/s, możesz ustawić bez wyzwalania operacji skalowania asynchronicznego (co wymaga, aby usługa Azure Cosmos DB aprowizować więcej partycji fizycznych), pomnożyć liczbę unikatowych identyfikatorów PartitionKeyRangeId o 10 0000 RU/s. Jeśli na przykład masz aprowizowaną 30 000 RU/s i 5 partycji fizycznych (6000 RU/s przydzielonych na partycję fizyczną), możesz zwiększyć do 50 000 RU/s (10 000 RU/s na partycję fizyczną) w natychmiastowej operacji skalowania w górę. Zwiększenie do >50 000 RU/s wymagałoby operacji asynchronicznej skalowania w górę. Dowiedz się więcej o najlepszych rozwiązaniach dotyczących skalowania aprowizowanej przepływności (RU/s).

Krok 3. Określanie, które żądania zwracają odpowiedzi 429

Jak badać żądania przy użyciu 429 odpowiedzi

Użyj dzienników diagnostycznych platformy Azure , aby zidentyfikować, które żądania zwracają 429 odpowiedzi i liczbę używanych jednostek RU. To przykładowe zapytanie agreguje na poziomie minuty.

Ważne

Włączenie dzienników diagnostycznych powoduje naliczanie oddzielnej opłaty za usługę Log Analytics, która jest rozliczana na podstawie ilości pozyskanych danych. Zaleca się włączenie dzienników diagnostycznych przez ograniczony czas na debugowanie i wyłączenie, gdy nie jest już wymagane. Aby uzyskać szczegółowe informacje, zobacz stronę cennika .

 CDBDataPlaneRequests
 | where TimeGenerated >= ago(24h)
 | summarize throttledOperations = dcountif(ActivityId, StatusCode == 429), totalOperations = dcount(ActivityId), totalConsumedRUPerMinute = sum(RequestCharge) by DatabaseName, CollectionName, OperationName, RequestResourceType, bin(TimeGenerated, 1min)
 | extend averageRUPerOperation = 1.0 * totalConsumedRUPerMinute / totalOperations
 | extend fractionOf429s = 1.0 * throttledOperations / totalOperations
 | order by fractionOf429s desc

Na przykład te przykładowe dane wyjściowe pokazują, że każda minuta, 30% żądań tworzenia dokumentów było ograniczonych, przy czym każde żądanie zużywa średnio 17 jednostek RU. Żądania z 429 w dziennikach diagnostycznych.

Korzystanie z planisty pojemności usługi Azure Cosmos DB

Możesz użyć planisty pojemności usługi Azure Cosmos DB , aby zrozumieć, jaka jest najlepsza aprowizowana przepływność na podstawie obciążenia (wolumin i typ operacji i rozmiaru dokumentów). Możesz dostosować dalsze obliczenia, dostarczając przykładowe dane w celu uzyskania dokładniejszego oszacowania.

429 odpowiedzi dotyczące żądań dokumentów tworzenia, zastępowania lub upsert
  • Domyślnie w interfejsie API for NoSQL wszystkie właściwości są domyślnie indeksowane. Dostosuj zasady indeksowania , aby indeksować tylko wymagane właściwości. Spowoduje to obniżenie liczby jednostek żądań wymaganych na operację tworzenia dokumentu, co zmniejszy prawdopodobieństwo wyświetlania odpowiedzi 429 lub umożliwi osiągnięcie wyższych operacji na sekundę dla tej samej ilości aprowizowanych jednostek RU/s.
429 odpowiedzi dotyczące żądań dokumentów zapytań
429 odpowiedzi na wykonywanie procedur składowanych
  • Procedury składowane są przeznaczone dla operacji wymagających transakcji zapisu w ramach wartości klucza partycji. Nie zaleca się używania procedur składowanych dla dużej liczby operacji odczytu lub zapytań. Aby uzyskać najlepszą wydajność, należy wykonać te operacje odczytu lub zapytań po stronie klienta przy użyciu zestawów SDK usługi Azure Cosmos DB.

Szybkość żądań jest duża z autoskalowaniem

Wszystkie wskazówki zawarte w tym artykule dotyczą przepływności ręcznej i automatycznej.

Podczas korzystania z autoskalowania często pojawia się pytanie : "Czy nadal można zobaczyć 429 odpowiedzi z autoskalowaniem?"

Tak. Istnieją dwa główne scenariusze, w których może się to zdarzyć.

Scenariusz 1: Gdy łączna liczba jednostek RU/s przekracza maksymalną liczbę RU/s bazy danych lub kontenera, usługa będzie odpowiednio ograniczać żądania. Jest to podobne do przekroczenia ogólnej ręcznej aprowizowanej przepływności bazy danych lub kontenera.

Scenariusz 2: Jeśli istnieje gorąca partycja, oznacza to, że wartość klucza partycji logicznej, która ma nieproporcjonalnie wyższą ilość żądań w porównaniu z innymi wartościami klucza partycji, istnieje możliwość przekroczenia budżetu jednostek RU/s bazowej partycji fizycznej. Najlepszym rozwiązaniem, aby uniknąć gorących partycji, jest wybranie właściwego klucza partycji, który zapewni równomierny rozkład magazynowania i przepływności. Jest to podobne do tego, gdy podczas korzystania z przepływności ręcznej występuje gorąca partycja.

Jeśli na przykład wybierzesz opcję maksymalnej przepływności 20 000 RU/s i masz 200 GB miejsca do magazynowania z czterema partycjami fizycznymi, każda partycja fizyczna może zostać automatycznie skalowana do 5000 RU/s. Jeśli na określonym kluczu partycji logicznej wystąpiła gorąca partycja, zobaczysz 429 odpowiedzi, gdy podstawowa partycja fizyczna, w której znajduje się, przekracza 5000 RU/s, czyli przekracza 100% znormalizowanego wykorzystania.

Postępuj zgodnie ze wskazówkami w kroku 1, kroku 2 i kroku 3 , aby debugować te scenariusze.

Innym typowym pytaniem jest: Dlaczego znormalizowane użycie jednostek RU wynosi 100%, ale skalowanie automatyczne nie zostało przeskalowane do maksymalnej liczby jednostek RU/s?

Zwykle występuje to w przypadku obciążeń, które mają tymczasowe lub sporadyczne skoki użycia. W przypadku korzystania z automatycznego skalowania usługa Azure Cosmos DB skaluje tylko jednostkę RU/s do maksymalnej przepływności, gdy znormalizowane użycie jednostek RU wynosi 100% dla trwałego, ciągłego okresu w 5-sekundowym interwale. Jest to realizowane w celu zapewnienia, że logika skalowania jest przyjazna dla użytkownika, ponieważ gwarantuje, że pojedyncze, chwilowe skoki nie prowadzą do niepotrzebnego skalowania i wyższych kosztów. Gdy występują chwilowe skoki, system zwykle skaluje w górę do wartości wyższej niż wcześniej skalowana do ru/s, ale niższa niż maksymalna liczba RU/s. Dowiedz się więcej na temat interpretowania metryki znormalizowanych użycia jednostek RU za pomocą autoskalowania.

Ograniczanie szybkości żądań metadanych

Ograniczanie szybkości metadanych może wystąpić, gdy wykonujesz dużą liczbę operacji metadanych w bazach danych i/lub kontenerach. Operacje metadanych obejmują:

  • Tworzenie, odczytywanie, aktualizowanie lub usuwanie kontenera lub bazy danych
  • Wyświetlanie listy baz danych lub kontenerów na koncie usługi Azure Cosmos DB
  • Zapytanie o oferty, aby wyświetlić bieżącą aprowizowaną przepływność

Istnieje limit jednostek RU zarezerwowanych dla systemu dla tych operacji, więc zwiększenie aprowizowanych jednostek RU/s bazy danych lub kontenera nie będzie miało wpływu i nie jest zalecane. Zobacz Limity usługi płaszczyzny sterowania.

Jak badać

Przejdź do obszaru Szczegółowe>informacje o żądaniach metadanychsystemu> według kodu stanu. Filtruj do określonej bazy danych i kontenera, jeśli jest to wymagane.

Żądania metadanych według wykresu kodu stanu w usłudze Insights.

  • Jeśli aplikacja musi wykonywać operacje metadanych, rozważ zaimplementowanie zasad wycofywania w celu wysyłania tych żądań z niższą szybkością.

  • Użyj statycznych wystąpień klienta usługi Azure Cosmos DB. Po zainicjowaniu klasy DocumentClient lub CosmosClient zestaw SDK usługi Azure Cosmos DB pobiera metadane dotyczące konta, w tym informacje o poziomie spójności, bazach danych, kontenerach, partycjach i ofertach. Ten proces inicjowania może zużyć dużą liczbę jednostek żądania i nie należy wykonywać go często. Używaj jednego wystąpienia DocumentClient przez cały cykl życia aplikacji.

  • Buforuj nazwy baz danych i kontenerów. Pobierz nazwy baz danych i kontenerów z konfiguracji lub buforuj je podczas uruchamiania. Wywołania takie jak ReadDatabaseAsync/ReadDocumentCollectionAsync lub CreateDatabaseQuery/CreateDocumentCollectionQuery spowodują wywołania metadanych do usługi, które zużywają limit jednostek RU zarezerwowanych przez system. Te operacje powinny być wykonywane rzadko.

Ograniczanie szybkości z powodu błędu usługi przejściowej

Ten błąd 429 jest zwracany, gdy żądanie napotka błąd usługi przejściowej. Zwiększenie jednostek RU/s w bazie danych lub kontenerze nie będzie miało wpływu i nie jest zalecane.

Ponów próbę żądania. Jeśli błąd będzie się powtarzać przez kilka minut, utwórz bilet pomocy technicznej z Azure Portal.

Następne kroki