"İstek hızı çok yüksek" (429) istisnalarını tanılama ve giderme

  • Şunlara uygulanır: ✅ NoSQL

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.

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 Bkz. MongoDB için API'deki yaygın sorunları giderme.

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 fazla tüketiyorsa Azure Cosmos DB 429 özel durumu döndürür. Her saniye, kullanılabilecek istek birimi sayısı sıfırlanır.

RU/sn'leri 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.

Tip

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 RU'lar 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.

Tip

Tüm işlemler, kullandıkları kaynak sayısına göre ücretlendirilir. Bu ücretler istek birimleriyle ölçülür. Bu ücretler, 400, 412 ve 449 gibi uygulama hataları nedeniyle başarıyla tamamlanamayan istekleri içerir. Sınırlama veya kullanım üzerinde düşünürken, bu işlemlerin sayısında bir artışa neden olacak şekilde bir kullanım düzeninin değişip değişmediğini araştırmak iyi bir fikirdir. Özellikle 412 veya 449 etiketlerini (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ına giriş.

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

429 hata iletisi görmek, veritabanınızda veya kapsayıcınızda sorun olduğu anlamına gelmez. Manuel veya otomatik ölçeklendirme aktarım hızı kullanmanızdan bağımsız olarak, 429 yanıtlarının küçük bir yüzdesi normaldir ve sağladığınız RU/sn değerini maksimuma çıkardığınızın bir göstergesidir.

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ü>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 ile toplu yürütücü kütüphanesi gibi veri içeri aktarma araçları, 429 hatalarında istekleri 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 Toplam Durum Koduna Göre İstekler grafiğinin ekran görüntüsü.

Genel olarak, bir üretim iş yükü için 429 yanıt içeren isteklerin %1-5 arasında olduğunu görüyorsanız ve uçtan uca gecikme süreniz kabul edilebilir düzeydeyse, bu RU/sn'lerin tam olarak kullanıldığının sağlıklı bir işaretidir. Eylem gerekmez. Aksi takdirde, sonraki sorun giderme adımlarına geçin.

Important

Bu 1-5% aralığı, hesap bölümlerinizin eşit olarak dağıtıldığını varsayar. Bölümleriniz eşit olarak dağıtılmadıysa, sorun bölümünüz çok sayıda 429 hata 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 istek 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ıcak bölüm olup olmadığını belirleme

Sıcak bölüm, bir veya birkaç mantıksal bölüm anahtarının daha yüksek istek hacmi nedeniyle toplam RU/sn'nin orantısız bir miktarını tüketmesiyle oluşur. Bunun nedeni istekleri eşit olarak dağıtmayan bir bölüm anahtarı tasarımı olabilir. Çok sayıda isteğin yoğun kullanılan mantıksal (fiziksel) bölümlerin küçük bir alt kümesine yönlendirilmesiyle sonuçlanır. Mantıksal bölümün tüm verileri tek bir fiziksel bölümde bulunduğundan ve toplam RU/sn fiziksel bölümler arasında eşit olarak dağıtıldığından, sıcak bir bölüm 429 yanıtlarına ve aktarım kapasitesinin verimsiz kullanımına yol açabilir.

Yüksek trafiğe sahip bölümlere yol açan bölümleme stratejilerine bazı örnekler aşağıda verilmiştir.

  • Yazma yoğunluklu iş yükü için date ile bölümlenen 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 da her gün sıcak bir bölüme yol açar.

    • Bunun yerine, bu senaryo için, id gibi bir bölüm anahtarı (GUID veya cihaz kimliği) veya ve id değerlerini birleştiren bir date yapay bölüm anahtarı, daha yüksek değer çeşitliliği ve istek hacminin daha dengeli bir dağılımını sağlar.

  • Bir tenantId tarafından bölümlenmiş kapsayıcı ile çok kiracılı bir senaryonuz var. Bir kiracı diğerlerinden çok daha etkinse, bu, yoğun erişim gören bir 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, tenantID ile bölümlendirdiğinizde sık erişimli bir bölüm oluşur.

    • Bu önceki senaryoda, UserId gibi daha ayrıntılı bir özelliğe göre bölümlenmiş en büyük kiracıya adanmış bir kapsayıcıya sahip olmayı düşünün.

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

Sık erişimli bir bölüm olup olmadığını doğrulamak için İçgörüler>Aktarım Hızı> altında Bölüm Anahtar Aralığı Kimliğine Göre Normalleştirilmiş RU Tüketimi (%) bölümüne gidin. Belirli bir veritabanı ve kapsayıcıya göre filtreleyin.

Her PartitionKeyRangeId, bir fiziksel bölüme karşılık gelir. Normalleştirilmiş RU tüketimi diğerlerinden çok daha yüksek olan bir PartitionKeyRangeId varsa (örneğin, biri tutarlı olarak 100%olduğunda, ancak diğerleri 30% veya daha az olduğunda), bu sık erişimli bölümün bir işareti olabilir. Normalleştirilmiş RU Tüketimi metriği hakkında daha fazla bilgi edinmek için bakınız: Azure Cosmos DB kapsayıcısı veya hesabı için normalleştirilmiş RU/s tüketimini izleme.

Sık erişimli bölüme sahip PartitionKeyRangeId tarafından normalleştirilmiş RU Tüketimini gösteren ekran görüntüsü.

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.

Important

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. Daha fazla bilgi edinmek için bkz.Azure İzleyici fiyatlandırması.

 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 tüketildiğini, Fabrikam değerinin 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ını gösteren sonuçların ekran görüntüsü.

Tip

Herhangi bir iş yükünde, mantıksal bölümler arasında istek hacminde doğal bir değişim vardır. Sıcak bölümün, bölüm anahtarı seçimi nedeniyle temel bir çarpıklık (ki bu, anahtarın değiştirilmesini gerektirebilir) veya iş yükü desenlerindeki doğal dalgalanmalardan kaynaklanan geçici bir ani artış 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:

  • İstemci SDK'larını, Azure portalını, PowerShell'i, CLI'yı veya ARM şablonunu kullanarak veritabanı veya kapsayıcıdaki RU/sn'leri artırabilirsiniz . Doğru RU/sn ayarını belirlemek için tahsis edilen aktarım hızını (RU/sn) ölçeklendirmeye yönelik en iyi uygulamaları izleyin.

Yüzde olarak yüksek bir hız sınırlı istek oranı varsa ve altta yatan bir sık erişimli bölüm mevcutsa:

  • Uzun vadede en iyi maliyet ve performans için 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 vadede, 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 aşırı kaynak ayrılmasına ve maliyetin artmasına yol açtığı için bu uzun vadeli bir strateji olarak önerilmez.
  • Kısa vadede, sık erişimli fiziksel bölüme daha fazla RU/sn atamak için aktarım hızını bölümler arasında yeniden dağıtabilirsiniz (önizleme). Bu yalnızca sıcak fiziksel bölüm tahmin edilebilir ve tutarlı olduğunda önerilir.

Tip

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ürer. 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 beş 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. Daha fazla bilgi edinmek için bkz. Sağlanan aktarım hızını (RU/sn) ölçeklendirmeye yönelik en iyi yöntemler.

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

429 yanıtları ile istekleri nasıl araştırılır

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.

Important

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. Daha fazla bilgi edinmek için bkz.Azure İzleyici fiyatlandırması.

 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ıda belge oluşturma isteklerinin her dakikası 30% hız sınırlı olduğu ve her isteğin ortalama 17 RU tükettiğini gösterir.

Tanılama Günlüklerinde 429 içeren istekleri gösteren ekran görüntüsü.

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 RU'ları azaltarak 429 yanıt görme olasılığını azaltır veya aynı miktarda sağlanan RU/sn 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ı çalıştırma sırasında 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 manuel hem de otomatik ölçeklendirme aktarım hızı için uygulanabilir.

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ü?"

Cevap 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ıcak 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 bir mantıksal bölüm anahtarı değeri varsa, temel alınan fiziksel bölümün RU/s bütçesini aşması mümkündür. Aşırı yüklenmiş bölümlerden kaçınmak için, depolama ve verim açısından eşit dağıtım sağlayan iyi bir bölüm anahtarı seçmek en iyi yöntemlerden biridir. Bu, manuel aktarım hızı kullanılırken yoğun kullanılan bölüm oluşması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ına sahip bir yoğun 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 Hata 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. Daha fazla bilgi edinmek için bkz. Normalleştirilmiş RU tüketimi ve otomatik ölçeklendirme.

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 yoktur ve önerilmez. Bkz. Denetim Düzlemi Hizmet Sınırları.

Araştırma adımları

Insights>Sistem>Durum Koduna Göre 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 isteklerinin ekran görüntüsü.

  • 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 çok sayıda RU tüketebilir ve seyrek olarak 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, sistem tarafından ayrılmış Talep Birimi (RU) sınırından harcayan hizmete yönelik 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ında veya kapsayıcıda RU/sn'yi artırmanın etkisi yoktur ve önerilmez.

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

Sonraki Adımlar

  • Last updated on