NoSQL için Azure Cosmos DB Java v4 SDK istek zaman aşımı istisnalarını tanılama ve sorun giderme

Http 408 hatası, yazılım geliştirme seti (SDK) zaman aşımı sınırı oluşmadan önce isteği tamamlayamadıysa oluşur.

Sorun giderme adımları

Aşağıdaki listede istek zaman aşımı özel durumlarının bilinen nedenleri ve çözümleri yer alır.

Uçtan uca zaman aşımı politikası

Buradaki tüm önleyici çözümler uygulandığında bile 408 ağ zaman aşımı hatalarının oluştuğu senaryolar vardır. Kuyruk gecikme süresini azaltmaya ve bu senaryolarda kullanılabilirliği geliştirmeye yönelik genel bir en iyi yöntem, uçtan uca zaman aşımı ilkesi uygulamaktır. Daha hızlı başarısız olarak kuyruk gecikme süresi azalır ve istek birimleri ile istemci tarafındaki işlem maliyetleri, zaman aşımından sonra yeniden denemeler durdurularak azaltılır. Zaman aşımı süresi CosmosItemRequestOptions üzerinde ayarlanabilir. Ardından seçenekler, NoSQL için Azure Cosmos DB'ye gönderilen tüm isteklere geçirilebilir:

CosmosEndToEndOperationLatencyPolicyConfig endToEndOperationLatencyPolicyConfig = new CosmosEndToEndOperationLatencyPolicyConfigBuilder(Duration.ofSeconds(1)).build();

CosmosItemRequestOptions options = new CosmosItemRequestOptions();
options.setCosmosEndToEndOperationLatencyPolicyConfig(endToEndOperationLatencyPolicyConfig);

container.readItem("id", new PartitionKey("pk"), options, TestObject.class);

Mevcut sorunlar

İsteklerin daha uzun süre takıldığını veya zaman aşımına uğradığını görüyorsanız lütfen Java v4 SDK'sını en son sürüme yükseltin. NOT: 4.18.0 ve üzeri sürümleri kullanmanızı kesinlikle öneririz. Daha fazla ayrıntı için Java v4 SDK sürüm notlarına göz atın.

Yüksek CPU kullanımı

Yüksek CPU kullanımı en yaygın durumdur. En uygun gecikme süresi için CPU kullanımı kabaca yüzde 40 olmalıdır. Maksimum (ortalama olmayan) CPU kullanımını izlemek için saniyeleri aralık olarak kullanın 10 . Ani CPU artışları, tek bir sorgu için birden çok bağlantı kurulabilen bölümler arası sorgularda daha yaygındır.

Solution

SDK'yı kullanan istemci uygulamasının ölçeği artırılmalı veya genişletilmelidir.

Bağlantı kısıtlaması

Bağlantı azaltma, ana bilgisayardaki bağlantı sınırı veya Azure'un kaynak ağ adresi çevirisi (SNAT) bağlantı noktası tükenmesi nedeniyle oluşabilir.

Konak makinede bağlantı sınırı

Red Hat gibi bazı Linux sistemlerinin toplam açık dosya sayısı üst sınırı vardır. Linux'taki yuvalar dosya olarak uygulandığından, bu sayı toplam bağlantı sayısını da sınırlar. Aşağıdaki komutu çalıştırın.

ulimit -a

Solution

olarak tanımlanan nofileizin verilen en fazla açık dosya sayısı en az 10.000 veya daha fazla olmalıdır. Daha fazla bilgi için bkz. NoSQL için Azure Cosmos DB Java SDK v4 performans ipuçları.

Bağlantı noktası veya soket kullanılabilirliği düşük olabilir

Çözümünüz Azure'da çalışırken Java SDK'sını kullanan istemciler Azure SNAT bağlantı noktası tükenmesine neden olabilir.

Çözüm 1

Azure VM'lerinde çalışıyorsanız SNAT bağlantı noktası tükenme kılavuzunu izleyin.

Çözüm 2

Azure Uygulaması Hizmeti'ni çalıştırıyorsanız bağlantı hataları sorun giderme kılavuzunu izleyin ve App Service tanılamasını kullanın.

Çözüm 3

Azure İşlevleri'ni çalıştırıyorsanız, ilgili tüm hizmetler (NoSQL için Azure Cosmos DB dahil) için tekil veya statik istemcilerin bakımının Azure İşlevleri önerisini izlediğinizi doğrulayın. İşlev Uygulaması barındırmanızın türüne ve boyutuna göre hizmet sınırlarını denetleyin.

Çözüm 4

HTTP ara sunucusu kullanıyorsanız, SDK'da GatewayConnectionConfigyapılandırılan bağlantı sayısını destekleyebilendiğinden emin olun. Aksi takdirde bağlantı sorunlarıyla karşılaşırsınız.

Birden çok istemci örneği oluşturma

Birden çok istemci örneği oluşturmak bağlantı çekişmesine ve zaman aşımı sorunlarına yol açabilir.

Çözüm 1

Performans ipuçlarını izleyin ve uygulamanın tamamında tek bir CosmosClient örneği kullanın.

Çözüm 2

Bir uygulamada teklinin CosmosClient olması mümkün değilse, CosmosClient'ta bu API connectionSharingAcrossClientsEnabled(true) aracılığıyla birden çok NoSQL için Azure Cosmos DB istemcisi arasında bağlantı paylaşımı kullanmanızı öneririz. İstemcinin birden çok hesapla etkileşim kuran birden çok örneğiniz varsa, bu ayarın etkinleştirilmesi Doğrudan modda bağlantı paylaşımına izin verir. Bu mod yalnızca NoSQL için Azure Cosmos DB istemcisi örnekleri arasında bağlantı paylaşımı mümkünse etkinleştirilir. Bu paylaşım seçeneğini ayarlarken, ilk örnek alınan istemcinin bağlantı yapılandırmasının (örneğin, yuva zaman aşımı yapılandırması, boşta kalma zaman aşımı yapılandırması) diğer tüm istemci örnekleri için kullanıldığını unutmayın.

Sık kullanılan bölüm anahtarı

NoSQL için Azure Cosmos DB, sağlanan genel aktarım hızını fiziksel bölümler arasında eşit olarak dağıtır. Yoğun kullanılan bir bölüm söz konusu olduğunda, fiziksel bölümdeki bir veya birden fazla mantıksal anahtar fiziksel bölümün saniye başına İstek Birimlerinin (RU/sn) tümünü tüketir. Bu sırada, diğer fiziksel bölümlerdeki RU/sn kullanılmamış olarak kalır. Belirti olarak, tüketilen toplam RU/sn, veritabanı veya kapsayıcıda sağlanan genel RU/sn değerinden daha azdır, ancak sıcak mantıksal bölüm anahtarına yönelik isteklerde sınırlama (429 hataları) görmeye devam edebilirsiniz. İş yükünün sıcak bir bölüme denk gelip gelmediğini görmek için Normalleştirilmiş RU Tüketim ölçütünü kullanın.

Solution

İstek hacmini ve depolama alanını eşit olarak dağıtan iyi bir bölüm anahtarı seçin. Bölüm anahtarınızı değiştirmeyi öğrenin.

Yüksek eşzamanlılık derecesi

Uygulama, kanalda çekişmeye neden olabilecek yüksek düzeyde eşzamanlılık yapıyor.

Solution

SDK'yı kullanan istemci uygulamasının ölçeği artırılmalı veya genişletilmelidir.

Büyük istekler veya yanıtlar

Büyük istekler veya yanıtlar kanalda satır başı engellemeye yol açabilir ve nispeten düşük eşzamanlılık derecesiyle bile çekişmeye neden olabilir.

Solution

SDK'yı kullanan istemci uygulamasının ölçeği artırılmalı veya genişletilmelidir.

Hata oranı, NoSQL için Azure Cosmos DB hizmet düzeyi sözleşmesi (SLA) kapsamındadır

Uygulamanın geçici hataları işleyebilmesi ve gerektiğinde yeniden deneme yapabilmesi gerekir. 408 özel durumları yeniden denenmiyor çünkü oluşturma yollarında hizmetin öğeyi oluşturup oluşturmadığını bilmek mümkün değildir. Oluşturma için aynı öğeyi tekrar göndermek, bir çakışma istisnasının ortaya çıkmasına neden olur. Kullanıcı uygulamaları iş mantığı, çakışmaları yönetmek için özel bir mantığa sahip olabilir ve bu da var olan bir öğenin belirsizliğinden veya bir oluşturma yeniden denemesinden kaynaklanan çakışmaları çözebilir.

Hata oranı NoSQL için Azure Cosmos DB SLA'sını ihlal ediyor

Azure Desteği'ne başvurun.

İlgili içerik

• NoSQL için Azure Cosmos DB Java v4 SDK'sını kullanırken karşılaşılan sorunları tanılayın ve giderin.
• Java v4 için performans yönergeleri hakkında bilgi edinin.