tanılama ve sorun giderme Azure Cosmos DB istek hızı çok büyük (429) özel durumlar

UYGULANDıĞı YER: SQL API

bu makale SQL apı 'si için çeşitli 429 durum kodu hatalarına yönelik bilinen nedenleri ve çözümleri içerir. MongoDB için API kullanıyorsanız, 16500 durum koduna hata ayıklama hakkında bilgi için bkz. MongoDB IÇIN API 'de yaygın sorunları giderme makalesi.

hata kodu 429 olarak da bilinen "istek hızı çok büyük" özel durumu, Azure Cosmos DB karşı isteklerinizin hız sınırlı 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 birimi (RU/sn) cinsinden ölçülen aktarım hızını ayarlarsınız. Okuma, yazma ve sorgular gibi hizmette gerçekleştirilen veritabanı işlemleri, bazı istek birimleri (ru) kullanır. İstek birimlerihakkında daha fazla bilgi edinin.

belirli bir saniye içinde, işlemler sağlanan istek birimlerinden daha fazla tüketiği için Azure Cosmos DB bir 429 özel durumu döndürür. Her saniye, kullanılabilir istek birimlerinin sayısı sıfırlanır.

RU/s 'yi değiştirmeye yönelik bir eylem yapmadan önce, hız sınırlaması ve temel sorunu gidermek için kök nedenini anlamak önemlidir.

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

İstek hızı büyük

En yaygın senaryo budur. Veriler üzerinde işlemler tarafından tüketilen istek birimleri sağlanan RU/s sayısını aştığında meydana gelir.

1. Adım: 429 hatası ile isteklerin yüzdesini belirleme ölçümlerini denetleyin

429 hata iletilerinin görmemesi, veritabanınız veya kapsayıcınızda bir sorun olduğu anlamına gelmez.

İnceleme

Başarılı isteklerin toplam sayısı ile karşılaştırıldığında, veritabanınıza veya kapsayıcınıza yönelik isteklerinizin yüzdesini, 429s ile sonuçlanmış olarak belirleme. Azure Cosmos DB hesabı dikey penceresinden, > > durum koduna göre Analizler istekleri toplam istek öğesine gidin. Belirli bir veritabanı ve kapsayıcıya filtre uygulayın.

varsayılan olarak, Azure Data Factory ve toplu yürütücü kitaplığı Azure Cosmos DB istemci sdk 'ları ve veri içeri aktarma araçları, istekleri 429s üzerinde otomatik olarak yeniden dener. Genellikle en fazla 9 kez yeniden dener. Sonuç olarak, ölçümlerde 429'ları görseniz de bu hatalar uygulamanıza geri döndürülmeyebilir.

429 ve 2xx isteklerinin sayısını gösteren durum kodu grafiğine göre toplam Istek sayısı.

Genel olarak, bir üretim iş yükü için, 429s ile isteklerin% 1-5 ' i ve uçtan uca gecikme süresinin kabul edilebilir olduğunu görürseniz, bu, RU/sn 'nin tam olarak kullanıldığı sağlıklı bir oturum açma işlemi olur. İşlem yapmanız gerekmez. Aksi takdirde, sonraki sorun giderme adımlarına geçin.

2. Adım: bir sıcak bölüm olup olmadığını belirleme

Bir veya birkaç mantıksal bölüm anahtarı, daha yüksek istek hacmi nedeniyle toplam RU/sn 'nin orantısız miktarını tükettiği bir sıcak bölüm ortaya çıkar. Bu, istekleri eşit olarak dağıtmayan bir bölüm anahtarı tasarımının oluşmasına neden olabilir. Birçok isteğin, "etkin" olan küçük bir mantıksal alt kümesine (fiziksel olarak) yönlendirilmesine neden olur. Bir mantıksal bölümün tüm verileri bir fiziksel bölümde yer aldığı ve toplam RU/sn fiziksel bölümler arasında eşit olarak dağıtıldığından, bir sıcak bölüm 429s ve verimsiz verimlilik kullanılmasına yol açabilir.

İşte, sık kullanılan bölümlere neden olan bölümleme stratejilerine ilişkin bazı örnekler:

  • Tarafından bölümlenen bir yazma ağır iş yükü için IoT cihaz verilerini depolayan bir kapsayıcıdır date . Tek bir tarih için 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, her gün etkin bir bölüm oluşmasına neden olur.
    • Bunun yerine, bu senaryo için id (bır GUID veya cihaz kimliği) gibi bir bölüm anahtarı ya da birleştiren bir yapay bölüm anahtarı ve id date daha yüksek değer kardinalitesi ve istek biriminin daha iyi bir şekilde dağıtılması.
  • Bir kapsayıcı tarafından bölümlenen bir çok kiracılı senaryonuz vardır tenantId . Bir kiracının bazıları diğerlerinden çok daha etkin ise, bu, etkin bir bölüme neden olur. Örneğin, en büyük kiracının 100.000 kullanıcısı varsa, ancak çoğu kiracıların 10 ' dan az kullanıcısı varsa, tarafından bölümlenmiş bir etkin bölümünüz olur tenantID .
    • Bu önceki senaryo için, gibi daha ayrıntılı bir özellik tarafından bölümlenen en büyük kiracı için ayrılmış bir kapsayıcıya sahip olmaya göz önünde bulundurun UserId .

Etkin bölümü belirleme

etkin bir bölüm olup olmadığını doğrulamak için, > > partitionkeyrangeıd tarafından Analizler üretilen iş normalleştirilmiş RU tüketimine (%) gidin. Belirli bir veritabanı ve kapsayıcıya filtre uygulayın.

Her Partitionkeyrangeıd bir fiziksel bölümle eşlenir. Diğerlerinden çok daha yüksek normalleştirilmiş RU tüketimine sahip bir Partitionkeyrangeıd varsa (örneğin, biri %100 oranında, ancak diğerleri %30 veya daha az), bu, sık erişimli bir bölümün işareti olabilir. NORMALLEŞTIRILMIŞ ru tüketim ölçümühakkında daha fazla bilgi edinin.

Etkin bir bölümle Partitionkeyrangeıd grafiğine göre normalleştirilmiş RU tüketimi.

Hangi mantıksal bölüm anahtarlarının en çok RU/sn tükettiğini 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 birimini toplar.

Önemli

Tanılama günlüklerini etkinleştirme, Log Analytics hizmeti için, alınan verilerin hacmine göre faturalandırılan ayrı bir ücret doğurur. 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 bkz. fiyatlandırma sayfası .

AzureDiagnostics
| where TimeGenerated >= ago(24hour)
| where Category == "PartitionKeyRUConsumption"
| where collectionName_s == "CollectionName" 
| where isnotempty(partitionKey_s)
// Sum total request units consumed by logical partition key for each second
| summarize sum(todouble(requestCharge_s)) by partitionKey_s, operationType_s, bin(TimeGenerated, 1s)
| order by sum_requestCharge_s desc

Bu örnek çıktı, belirli bir dakika içinde, "contoso" değerli mantıksal bölüm anahtarının 12.000 RU/sn etrafında tüketilirken, "Fabrikam" değerine sahip mantıksal bölüm anahtarı 600 RU/s ' den daha az tüketilir. Bu model, oran sınırlandırma 'nin gerçekleştiği süre içinde tutarlıysa, bu bir sıcak bölüm gösterir.

Saniye başına en fazla istek birimini kullanan mantıksal bölüm anahtarları.

İpucu

Herhangi bir iş yükünde, istek hacminde mantıksal bölümler arasında doğal değişim olur. İş yükü desenlerinde doğal değişim nedeniyle, bölüm anahtarı seçimi (anahtarın değiştirilmesi gerekebilir) veya geçici ani artış nedeniyle, etkin bölümün neden temel bir çarpıklık kaynaklanıp kaynaklanmadığını belirlemelisiniz.

İyi bölüm anahtarını nasıl seçeceğinizeilişkin kılavuzu gözden geçirin.

Hız sınırlı isteklerin yüksek oranda yüzdesi varsa ve etkin bölüm yoksa:

Hız sınırlı isteklerin yüksek oranda yüzdesi varsa ve temel bir etkin bölüm varsa:

  • Uzun süreli, 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ı ile yeni bir kapsayıcıya geçirilmesi gerekir. Azure Cosmos DB bu amaçla bir dinamik veri geçiş aracını destekler.
  • Kısa süreli, etkin bölüme daha fazla aktarım hızı sağlamak için RU/s 'yi geçici olarak artırabilirsiniz. Bu, uzun süreli bir strateji olarak önerilmez, bu da RU/s ve daha yüksek maliyetli sağlama konusunda yol açar.

İpucu

Aktarım hızını artırdığınızda, ölçek artırma işlemi, ölçeklendirmek istediğiniz RU/sn sayısına bağlı olarak, anında ' yi tamamlar veya tamamlaması gereken 5-6 saat kadar sürebilir. zaman uyumsuz ölçek artırma işlemini tetiklemeden ayarlayabileceğiniz en yüksek RU/sn sayısını (daha fazla fiziksel bölüm sağlamak için Azure Cosmos DB gerektiren) biliyorsanız, farklı partitionkeyrangeıds sayısını 10, 0000 RU/sn ile çarpın. Örneğin, 30.000 RU/sn ve 5 fiziksel bölüm (fiziksel bölüm başına ayrılan 6000 RU/sn) varsa, anlık bir genişleme işleminde 50.000 RU/sn (fiziksel bölüm başına 10.000 RU/sn) ile artırabilirsiniz. >50.000 RU/sn 'ye artırmak zaman uyumsuz bir genişleme işlemi gerektirir.

3. Adım: hangi isteklerin 429'ı döndüleştirir belirleme

429s ile istekleri araştırma

Hangi isteklerin 429'ı döndüleceğini ve ne kadar RUs tükettiğini belirlemek için Azure tanılama günlüklerini kullanın. Bu örnek sorgu, dakika düzeyinde toplamalar toplar.

Önemli

Tanılama günlüklerini etkinleştirme, Log Analytics hizmeti için ayrı bir ücret sunarak, alınan verilerin 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 bkz. fiyatlandırma sayfası .

AzureDiagnostics
| where TimeGenerated >= ago(24h)
| where Category == "DataPlaneRequests"
| summarize throttledOperations = dcountif(activityId_g, statusCode_s == 429), totalOperations = dcount(activityId_g), totalConsumedRUPerMinute = sum(todouble(requestCharge_s)) by databaseName_s, collectionName_s, OperationName, requestResourceType_s, 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 her bir dakikalık, belge oluşturma isteklerinin %30 ' luk oranındaki her bir isteğin ortalama 17 ru 'yi tükettiği gösterilmektedir. Tanılama günlüklerinde 429 ile istekler.

oluşturma, değiştirme veya büyük belge isteklerinde 429s
  • varsayılan olarak, SQL apı 'sinde, tüm özellikler varsayılan olarak dizinlenir. Dizin oluşturma ilkesini yalnızca gerekli özellikleri dizinleyecek şekilde ayarlayın. Bu, her belge oluştur işlemi için gerekli olan Istek birimlerini düşürür, bu da 429s 'yi görüntüleme olasılığını azaltır veya aynı sağlanan RU/sn miktarı için saniye başına daha yüksek işlem elde etmenizi sağlar.
sorgu belgesi isteklerinde 429s
saklı yordamları yürütmek için 429s
  • Saklı yordamlar , bölüm anahtarı değerinde 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ı elde etmek için, bu okuma veya sorgu işlemleri istemci tarafında Cosmos sdk 'ları kullanılarak yapılmalıdır.

Meta veri isteklerinde hız sınırlandırma

Veritabanlarında ve/veya kapsayıcılarda yüksek hacimli meta veri işlemleri gerçekleştirerek meta veri hızı sınırlaması oluşabilir. Meta veri işlemleri şunları içerir:

  • Kapsayıcı veya veritabanı oluşturma, okuma, güncelleştirme veya silme
  • Bir hesapta veritabanlarını veya kapsayıcıları Cosmos listele
  • 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ış RU sınırı vardır, bu nedenle veritabanı veya kapsayıcının sağlanan RU/sn'lerinin artırılmasının herhangi bir etkisi olmaz ve önerilmez. Bkz. meta veri işlemleriyle ilgili sınırlar.

Araştırma

Durum Koduna Analizler > Sistem > Meta Veri İstekleri'ne gidin. İsterseniz belirli bir veritabanına ve kapsayıcıya filtre uygulama.

Analizler'da durum kodu grafiğine göre meta Analizler.

  • Uygulamanıza meta veri işlemleri yapılması gerekirse, bu istekleri daha düşük bir hıza göndermek için bir geri gönderme ilkesi uygulamayı göz önünde bulundurabilirsiniz.

  • Statik veritabanı Cosmos örneklerini kullanın. DocumentClient veya CosmosClient başlatılırken, 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 hesapla ilgili 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. Yapılandırmadan veritabanlarınızı ve kapsayıcılarınızı adlarını alın veya başlatmada önbelleğe alın. ReadDatabaseAsync/ReadDocumentCollectionAsync veya CreateDatabaseQuery/CreateDocumentCollectionQuery gibi çağrılar, sistem tarafından ayrılmış RU sınırını tüketen hizmete meta veri çağrılarına neden olur. Bu işlemler seyrek gerçekleştiriliyor.

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

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

İsteği yeniden deneyin. Hata birkaç dakika boyunca devam ederse, Azure portal.

Sonraki adımlar