Aracılığıyla paylaş

Azure Cosmos DB istek oranı çok yüksek (429) özel durumlarını tanılama ve sorun giderme

  • Makale

UYGULANANLAR: NoSQL

Bu makale, NoSQL API'sine yönelik çeşitli 429 durum kodu hatalarının bilinen nedenlerini ve çözümlerini içerir. MongoDB api'sini kullanıyorsanız, 16500 durum kodunda hata ayıklama için MongoDB IÇIN API'de yaygın sorunları giderme makalesine bakın.

Hata kodu 429 olarak da bilinen "İstek oranı çok büyük" özel durumu, Azure Cosmos DB'ye yönelik isteklerinizin hız sınırlaması olduğunu gösterir.

Sağlanan aktarım hızını kullandığınızda, iş yükünüz için gereken saniye başına istek birimleri (RU/sn) cinsinden ölçülen aktarım hızını ayarlarsınız. Okumalar, yazmalar ve sorgular gibi hizmete karşı veritabanı işlemleri bazı sayıda istek birimi (RU) tüketir. İstek birimleri hakkında daha fazla bilgi edinin.

Belirli bir saniyede, işlemler sağlanan istek birimlerinden daha fazlasını kullanırsa Azure Cosmos DB 429 özel durumu döndürür. Her saniye, kullanılabilecek istek birimi sayısı sıfırlanır.

RU/sn'yi değiştirmek için bir eylem gerçekleştirmeden önce hız sınırlamasının kök nedenini anlamak ve temel sorunu çözmek önemlidir.

İpucu

Bu makaledeki kılavuz, sağlanan aktarım hızını kullanan veritabanları ve kapsayıcılar için geçerlidir ; hem otomatik ölçeklendirme hem de el ile aktarım hızı.

Farklı 429 özel durum türlerine karşılık gelen farklı hata iletileri vardır:

İstek oranı büyük

Bu en yaygın senaryodur. Veriler üzerindeki işlemler tarafından kullanılan istek birimleri sağlanan RU/sn sayısını aştığında oluşur. El ile aktarım hızı kullanıyorsanız, sağlanan el ile aktarım hızından daha fazla RU/sn kullandığınızda bu durum oluşur. Otomatik ölçeklendirme kullanıyorsanız, sağlanan maksimum RU/sn'den daha fazlasını kullandığınızda bu durum oluşur. Örneğin, el ile 400 RU/sn aktarım hızıyla sağlanan bir kaynağınız varsa, tek bir saniyede 400'den fazla istek birimi kullandığınızda 429 değerini görürsünüz. Otomatik ölçeklendirme maksimum RU/sn değeri 4000 RU/sn (400 RU/sn - 4000 RU/sn arasında ölçeklendirilir) ile sağlanan bir kaynağınız varsa, tek bir saniyede 4000'den fazla istek birimi kullandığınızda 429 yanıt görürsünüz.

İpucu

Tüm işlemler, kullandıkları kaynak sayısına göre ücretlendirilir. Bu ücretler istek birimleriyle ölçülür. Bu ücretler, , 412, 449vb. gibi 400uygulama hatalarından dolayı başarıyla tamamlanmayan istekleri içerir. Azaltmaya veya kullanıma bakarken, kullanımınızda bu işlemlerin artmasına neden olacak bir desenin değişip değişmediğini araştırmak iyi bir fikirdir. Özellikle etiketleri 412 veya 449 (gerçek çakışma) denetleyin.

Sağlanan aktarım hızı hakkında daha fazla bilgi için bkz . Azure Cosmos DB'de sağlanan aktarım hızı.

1. Adım: 429 hatasıyla isteklerin yüzdesini belirlemek için ölçümleri denetleyin

429 hata iletilerini görmek, veritabanınızda veya kapsayıcınızda sorun olduğu anlamına gelmez. El ile veya otomatik ölçeklendirme aktarım hızı kullanmanız fark etmeksizin 429 yanıtın küçük bir yüzdesi normaldir ve sağladığınız RU/sn değerini en üst düzeye çıkardığınızın işaretidir.

Araştırma adımları

Veritabanınıza veya kapsayıcınıza yönelik isteklerinizin yüzde kaçının başarılı isteklerin toplam sayısına kıyasla 429 yanıta neden olduğunu belirleyin. Azure Cosmos DB hesabınızdan, Durum Koduna Göre İçgörü>İstekleri>Toplam İstekler'e gidin. Belirli bir veritabanı ve kapsayıcıya göre filtreleyin.

Varsayılan olarak, Azure Cosmos DB istemci SDK'ları ve Azure Data Factory ve toplu yürütücü kitaplığı gibi veri içeri aktarma araçları istekleri 429'larda otomatik olarak yeniden dener. Genellikle en fazla dokuz kez yeniden dener. Sonuç olarak ölçümlerde 429 yanıt görebilirsiniz ancak bu hatalar uygulamanıza döndürülmemiş bile olabilir.

429 ve 2xx istek sayısını gösteren Durum Koduna Göre Toplam İstek sayısı grafiği.

Genel olarak, bir üretim iş yükü için, 429 yanıtlı isteklerin %1-5'i arasında bir değer görürseniz ve uçtan uca gecikmeniz kabul edilebilirse, bu RU/sn'lerin tam olarak kullanıldığına ilişkin sağlıklı bir işarettir. Eylem gerekmiyor. Aksi takdirde, sonraki sorun giderme adımlarına geçin.

Önemli

Bu %1-5 aralığı, hesap bölümlerinizin eşit olarak dağıtıldığını varsayar. Bölümleriniz eşit olarak dağıtılmıyorsa, sorun bölümünüz büyük miktarda 429 hatası döndürebilirken genel oran düşük olabilir.

Otomatik ölçeklendirme kullanıyorsanız, RU/sn en yüksek RU/sn'ye ölçeklendirilmemiş olsa bile veritabanınızda veya kapsayıcınızda 429 yanıt görebilirsiniz. Açıklama için otomatik ölçeklendirme ile İstek oranı büyük bölümüne bakın.

Sık sorulan sorulardan biri şudur: "Azure İzleyici ölçümlerinde neden 429 yanıt görüyorum, ancak kendi uygulama izlememde yok?" Azure İzleyici Ölçümleri 429 yanıtınız olduğunu gösteriyorsa ancak kendi uygulamanızda hiç yanıt görmediyseniz, bunun nedeni varsayılan olarak Azure Cosmos DB istemci SDK'larının automatically retried internally on the 429 responses ve isteğin sonraki yeniden denemelerde başarılı olmasıdır. Sonuç olarak, 429 durum kodu uygulamaya döndürülmüyor. Bu gibi durumlarda, genel oranın %1-5 arasında olduğu ve uçtan uca gecikme süresinin uygulamanız için kabul edilebilir olduğu varsayıldığında 429 yanıtın genel oranı genellikle en düşük düzeydedir ve güvenle yoksayılabilir.

2. Adım: Sık erişimli bölüm olup olmadığını belirleme

Sık erişimli bölüm, bir veya birkaç mantıksal bölüm anahtarı daha yüksek istek hacmi nedeniyle toplam RU/sn'nin orantısız bir miktarını tükettiğinde ortaya çıkar. Bunun nedeni istekleri eşit olarak dağıtmayan bir bölüm anahtarı tasarımı olabilir. Birçok isteğin "sık erişimli" duruma gelen küçük bir mantıksal (fiziksel) bölüm alt kümesine yönlendirilmesiyle sonuçlanır. Mantıksal bölümün tüm verileri bir fiziksel bölümde bulunduğundan ve toplam RU/sn fiziksel bölümler arasında eşit olarak dağıtıldığı için, sık erişimli bölüm 429 yanıta ve verimsiz aktarım hızı kullanımına yol açabilir.

Sık erişimli bölümlere yol açan bölümleme stratejilerine bazı örnekler aşağıda verilmiştir:

  • tarafından datebölümlenmiş yoğun yazma iş yükü için IoT cihaz verilerini depolayan bir kapsayıcınız var. Tek bir tarihe ilişkin tüm veriler aynı mantıksal ve fiziksel bölümde yer alır. Her gün yazılan tüm veriler aynı tarihe sahip olduğundan, bu durum her gün sık erişimli bölüme neden olur.
    • Bunun yerine, bu senaryo için gibi bir bölüm anahtarı id (GUID veya cihaz kimliği) veya yapay bir bölüm anahtarı bir araya getirerek iddate değerlerin daha yüksek kardinalitesini ve istek hacminin daha iyi dağıtılmasını sağlar.
  • tarafından bölümlenmiş tenantIdbir kapsayıcı ile çok kiracılı bir senaryonuz var. Bir kiracı diğerlerinden çok daha etkinse, sık erişimli bölümle sonuçlanır. Örneğin, en büyük kiracının 100.000 kullanıcısı varsa ancak çoğu kiracının 10'dan az kullanıcısı varsa, tarafından tenantIDbölümlendiğinde sık erişimli bölüme sahip olursunuz.
    • Bu önceki senaryoda, gibi daha ayrıntılı bir özellik UserIdtarafından bölümlenmiş en büyük kiracı için ayrılmış bir kapsayıcıya sahip olmayı göz önünde bulundurun.

Sık erişimli bölümü tanımlama

Sık erişimli bölüm olup olmadığını doğrulamak için İçgörü aktarım>hızı>Normalleştirilmiş RU Tüketimi (%) By PartitionKeyRangeID bölümüne gidin. Belirli bir veritabanı ve kapsayıcıya göre filtreleyin.

Her PartitionKeyRangeId, bir fiziksel bölüme eşler. Normalleştirilmiş RU tüketimi diğerlerinden çok daha yüksek olan bir PartitionKeyRangeId varsa (örneğin, biri tutarlı olarak %100'de, diğerleri %30 veya daha azsa), bu sık erişimli bölümün işareti olabilir. Normalleştirilmiş RU Tüketimi ölçümü hakkında daha fazla bilgi edinin.

Sık erişimli bölüme sahip PartitionKeyRangeId grafiğine göre normalleştirilmiş RU Tüketimi.

Hangi mantıksal bölüm anahtarlarının en çok RU/sn kullandığını görmek için Azure Tanılama Günlükleri'ni kullanın. Bu örnek sorgu, her mantıksal bölüm anahtarında saniye başına tüketilen toplam istek birimlerini özetler.

Önemli

Tanılama günlüklerinin etkinleştirilmesi Log Analytics hizmeti için ayrı bir ücretlendirilir ve alınan veri hacmine göre faturalandırılır. Hata ayıklama için tanılama günlüklerini sınırlı bir süre için açmanız ve artık gerekli olmadığında kapatmanız önerilir. Ayrıntılar için fiyatlandırma sayfasına bakın.

 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

Bu örnek çıktı, belirli bir dakika içinde "Contoso" değerine sahip mantıksal bölüm anahtarının yaklaşık 12.000 RU/sn, "Fabrikam" değerine sahip mantıksal bölüm anahtarının ise 600 RU/sn'den az tüketildiğini gösterir. Bu desen, hız sınırlamasının gerçekleştiği zaman aralığında tutarlıysa bu, sık erişimli bir bölüm olduğunu gösterir.

Saniyede en fazla istek birimini kullanan mantıksal bölüm anahtarları.

İpucu

Herhangi bir iş yükünde, mantıksal bölümler arasında istek hacminde doğal bir değişim olacaktır. Sık erişimli bölümün, bölüm anahtarı seçiminden (anahtarın değiştirilmesini gerektirebilir) veya iş yükü desenlerindeki doğal değişim nedeniyle geçici bir ani artıştan kaynaklanan temel bir dengesizlik olup olmadığını belirlemeniz gerekir.

İyi bir bölüm anahtarı seçme yönergelerini gözden geçirin.

Hız sınırlı isteklerin yüzdesi yüksekse ve sık erişimli bölüm yoksa:

Hız sınırlı isteklerin yüzdesi yüksekse ve temel alınan bir sık erişimli bölüm varsa:

  • En iyi maliyet ve performans için uzun vadeli bölüm anahtarını değiştirmeyi göz önünde bulundurun. Bölüm anahtarı yerinde güncelleştirilemez, bu nedenle verilerin farklı bir bölüm anahtarına sahip yeni bir kapsayıcıya geçirilmesi gerekir. Azure Cosmos DB bu amaçla bir dinamik veri geçiş aracını destekler.
  • Kısa vadeli olarak, sık erişimli bölüme daha fazla aktarım hızı sağlamak için kaynağın genel RU/sn değerini geçici olarak artırabilirsiniz. Ru/sn'nin fazla sağlanmasına ve maliyetin daha yüksek olmasına yol açtığı için bu uzun vadeli bir strateji olarak önerilmez.
  • Kısa vadeli olarak, sık erişimli fiziksel bölüme daha fazla RU/sn atamak için bölümler arasında aktarım hızı yeniden dağıtım özelliğini (önizleme) kullanabilirsiniz. Bu yalnızca sık erişimli fiziksel bölüm tahmin edilebilir ve tutarlı olduğunda önerilir.

İpucu

Aktarım hızını artırdığınızda, ölçeği artırmak istediğiniz RU/sn sayısına bağlı olarak ölçeği artırma işlemi anında tamamlanır veya tamamlanması 5-6 saate kadar sürebilir. Zaman uyumsuz ölçeklendirme işlemini tetiklemeden ayarlayabileceğiniz en yüksek RU/sn sayısını bilmek istiyorsanız (daha fazla fiziksel bölüm sağlamak için Azure Cosmos DB gerektirir), ayrı PartitionKeyRangeId sayısını 10.0000 RU/sn ile çarpın. Örneğin, sağlanan 30.000 RU/sn ve 5 fiziksel bölümünüz (fiziksel bölüm başına 6000 RU/sn) varsa, anlık ölçeklendirme işleminde 50.000 RU/sn'ye (fiziksel bölüm başına 10.000 RU/sn) artırabilirsiniz. 50.000 RU/sn'ye çıkılması >zaman uyumsuz bir ölçeklendirme işlemi gerektirir. Sağlanan aktarım hızını (RU/sn) ölçeklendirmeye yönelik en iyi yöntemler hakkında daha fazla bilgi edinin.

3. Adım: Hangi isteklerin 429 yanıt döndüreceğini belirleme

429 yanıtla istekleri araştırma

Hangi isteklerin 429 yanıt döndürüp kaç RU kullandığını belirlemek için Azure Tanılama Günlükleri'ni kullanın. Bu örnek sorgu dakika düzeyinde toplanır.

Önemli

Tanılama günlüklerinin etkinleştirilmesi Log Analytics hizmeti için ayrı bir ücretlendirilir ve alınan veri hacmine göre faturalandırılır. Tanılama günlüklerini hata ayıklama için sınırlı bir süre için açmanız ve artık gerekli olmadığında kapatmanız önerilir. Ayrıntılar için fiyatlandırma sayfasına bakın.

 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

Örneğin, bu örnek çıktı, belge oluşturma isteklerinin her dakikasının %30'unun hız sınırlı olduğunu ve her isteğin ortalama 17 RU tükettiğini gösterir. Tanılama Günlüklerinde 429 ile istekler.

Azure Cosmos DB kapasite planlayıcısını kullanma

Azure Cosmos DB kapasite planlayıcısını kullanarak iş yükünüz temelinde en iyi sağlanan aktarım hızının ne olduğunu anlayabilirsiniz (işlem hacmi ve türü ve belgelerin boyutu). Daha doğru bir tahmin elde etmek için örnek veriler sağlayarak hesaplamaları daha da özelleştirebilirsiniz.

Belge istekleri oluşturma, değiştirme veya yükseltme işlemleriyle ilgili 429 yanıt
  • Varsayılan olarak, NoSQL API'sinde tüm özellikler varsayılan olarak dizine eklenir. Dizin oluşturma ilkesini yalnızca gerekli özellikleri dizine almak için ayarlayın. Bu, belge oluşturma işlemi başına gereken İstek Birimlerini azaltır ve bu da 429 yanıt görme olasılığını azaltır veya sağlanan RU/sn miktarı için saniyede daha yüksek işlemler gerçekleştirmenize olanak tanır.
Sorgu belgesi isteklerinde 429 yanıt
  • Yüksek RU ücretine sahip sorgularla ilgili sorunları gidermek için kılavuzu izleyin
Saklı yordamları yürütmede 429 yanıt
  • Saklı yordamlar , bir bölüm anahtarı değeri genelinde yazma işlemleri gerektiren işlemlere yöneliktir. Çok sayıda okuma veya sorgu işlemi için saklı yordamların kullanılması önerilmez. En iyi performans için bu okuma veya sorgu işlemleri Azure Cosmos DB SDK'ları kullanılarak istemci tarafında yapılmalıdır.

otomatik ölçeklendirme ile istek oranı büyük

Bu makaledeki tüm yönergeler hem el ile hem de otomatik ölçeklendirme aktarım hızı için geçerlidir.

Otomatik ölçeklendirme kullanılırken sık sorulan bir soru şudur: "Otomatik ölçeklendirme ile 429 yanıtı görmek hala mümkün mü?"

Evet. Bunun gerçekleşebileceği iki ana senaryo vardır.

Senaryo 1: Genel olarak tüketilen RU/sn veritabanı veya kapsayıcının maksimum RU/sn değerini aştığında, hizmet istekleri buna göre kısıtlar. Bu, bir veritabanı veya kapsayıcının genel el ile sağlanan aktarım hızını aşmaya benzer.

Senaryo 2: Sık erişimli bir bölüm varsa, yani diğer bölüm anahtarı değerlerine kıyasla orantısız olarak daha yüksek istek miktarına sahip mantıksal bölüm anahtarı değeri varsa, temel alınan fiziksel bölümün RU/sn bütçesini aşması mümkündür. Sık erişimli bölümlerle karşılaşmamak için kullanabileceğiniz en iyi yöntemlerden biri, depolama ve işlem hızı konusunda eşit dağıtım sağlayan iyi bir bölüm anahtarı seçmektir. Bu, el ile aktarım hızı kullanılırken sık erişimli bölüm olmasına benzer.

Örneğin, 20.000 RU/sn maksimum aktarım hızı seçeneğini belirlerseniz ve dört fiziksel bölüm içeren 200 GB depolama alanınız varsa, her fiziksel bölüm 5000 RU/sn'ye kadar otomatik olarak ölçeklendirilebilir. Belirli bir mantıksal bölüm anahtarında sık erişimli bölüm varsa, içinde bulunduğu temel alınan fiziksel bölüm 5000 RU/sn'yi aştığında,yani %100 normalleştirilmiş kullanımı aştığında 429 yanıt görürsünüz.

Bu senaryolarda hata ayıklamak için 1. Adım, 2. Adım ve 3. Adım'daki yönergeleri izleyin.

Sık sorulan bir diğer soru da neden %100 normalleştirilmiş RU tüketimidir, ancak otomatik ölçeklendirme en yüksek RU/sn'ye ölçeklendirilmemiş olabilir?

Bu genellikle geçici veya aralıklı kullanım artışları olan iş yükleri için oluşur. Otomatik ölçeklendirmeyi kullandığınızda Azure Cosmos DB, 5 saniyelik bir aralıkta sürekli ve sürekli bir süre boyunca normalleştirilmiş RU tüketimi %100 olduğunda RU/sn'yi yalnızca maksimum aktarım hızına ölçeklendirir. Bu, tek ve anlık ani artışların gereksiz ölçeklendirmeye ve daha yüksek maliyete yol açmamasını sağladığından ölçeklendirme mantığının kullanıcıya uygun maliyetli olmasını sağlamak için yapılır. Anlık ani artışlar olduğunda, sistem genellikle daha önce RU/sn olarak ölçeklendirilen değerden daha yüksek ancak en yüksek RU/sn'den daha düşük bir değere ölçeklendirilir. Otomatik ölçeklendirme ile normalleştirilmiş RU tüketim ölçümünü yorumlama hakkında daha fazla bilgi edinin.

Meta veri isteklerinde hız sınırlama

Veritabanlarında ve/veya kapsayıcılarda yüksek hacimli meta veri işlemleri gerçekleştirdiğinizde meta veri hızı sınırlaması oluşabilir. Meta veri işlemleri şunlardır:

  • Kapsayıcı veya veritabanı oluşturma, okuma, güncelleştirme veya silme
  • Azure Cosmos DB hesabındaki veritabanlarını veya kapsayıcıları listeleme
  • Sağlanan geçerli aktarım hızını görmek için teklifleri sorgulama

Bu işlemler için sistem tarafından ayrılmış bir RU sınırı vardır, bu nedenle veritabanı veya kapsayıcının sağlanan RU/sn'lerini artırmanın hiçbir etkisi olmaz ve önerilmez. Bkz. Denetim Düzlemi Hizmet Sınırları.

Araştırma adımları

Durum Koduna Göre İçgörüler>Sistem>Meta Veri İstekleri'ne gidin. İsterseniz belirli bir veritabanı ve kapsayıcıya göre filtreleyin.

İçgörüler'de durum kodu grafiğine göre meta veri istekleri.

  • Uygulamanızın meta veri işlemleri gerçekleştirmesi gerekiyorsa, bu istekleri daha düşük bir hızda göndermek için bir geri alma ilkesi uygulamayı göz önünde bulundurun.

  • Statik Azure Cosmos DB istemci örneklerini kullanın. DocumentClient veya CosmosClient başlatıldığında Azure Cosmos DB SDK'sı tutarlılık düzeyi, veritabanları, kapsayıcılar, bölümler ve teklifler hakkında bilgiler de dahil olmak üzere hesap hakkındaki meta verileri getirir. Bu başlatma işlemi çok sayıda RU kullanabileceğinden seyrek gerçekleştirilmelidir. Tek bir DocumentClient örneğini, uygulamanızın yaşam ömrü boyunca kullanın.

  • Veritabanlarının ve kapsayıcıların adlarını önbelleğe alın. Veritabanlarınızın ve kapsayıcılarınızın adlarını yapılandırmadan alın veya başlangıçta önbelleğe alın. ReadDatabaseAsync/ReadDocumentCollectionAsync veya CreateDatabaseQuery/CreateDocumentCollectionQuery gibi çağrılar, sisteme ayrılmış RU sınırından kullanan hizmete meta veri çağrılarına neden olur. Bu işlemler seyrek gerçekleştirilmelidir.

Geçici hizmet hatası nedeniyle hız sınırlama

İstek geçici bir hizmet hatasıyla karşılaştığında bu 429 hatası döndürülür. Veritabanı veya kapsayıcıda RU/sn'yi artırmanın hiçbir etkisi olmaz ve önerilmez.

İsteği yeniden deneyin. Hata birkaç dakika devam ederse Azure portalından bir destek bileti oluşturun.

Sonraki adımlar