Aracılığıyla paylaş

Azure Cosmos DB Java v4 SDK istek zaman aşımı özel durumlarını tanılama ve sorun giderme

  • Makale

UYGULANANLAR: NoSQL

HTTP 408 hatası, zaman aşımı sınırına ulaşılana kadar SDK'nın isteği tamamlayamaması durumunda oluşur.

Sorun giderme adımları

Aşağıdaki liste istek zaman aşımı istisnaları için bilinen nedenleri ve çözümleri içerir.

Uçtan uca zaman aşımı ilkesi

Aşağıda belirtilen tüm önleyici çözümler uygulandığında bile 408 ağ zaman aşımı hatalarının oluşacağı senaryolar vardır. Kuyruk gecikme süresini azaltmanın yanı sıra bu senaryolarda kullanılabilirliği iyileştirmeye yönelik genel bir en iyi yöntem, uçtan uca zaman aşımı ilkesi uygulamaktır. Kuyruk gecikme süresi daha hızlı başarısız olursa azalır ve zaman aşımından sonra yeniden denemeler durdurularak istek birimleri ve istemci tarafı işlem maliyetleri azalır. Zaman aşımı süresi üzerinde CosmosItemRequestOptionsayarlanabilir. Ardından seçenekler 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 değil) CPU kullanımını izlemek için 10 saniyelik bir zaman aralığı kullanın. Ani CPU artışları, tek bir sorgu için birden çok bağlantı kurulabilen bölümler arası sorgularda daha yaygındır.

Çözüm:

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

Bağlantı azaltma

Bağlantı azaltma, konak makinedeki bağlantı sınırı veya Azure SNAT (PAT) 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

Çözüm:

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

Yuva veya bağlantı noktasının kullanılabilirliği düşük olabilir

Azure'da çalışırken Java SDK'sını kullanan istemciler Azure SNAT (PAT) bağlantı noktası tükenmesine neden olabilir.

1. Çözüm:

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

2. Çözüm:

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 çalıştırıyorsanız, tüm ilgili hizmetler (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şmesi ve zaman aşımı sorunlarına yol açabilir.

1. Çözüm:

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

2. Çözüm:

Singleton CosmosClient'ın bir uygulamada olması mümkün değilse, CosmosClient'da bu API connectionSharingAcrossClientsEnabled(true) aracılığıyla birden çok Azure Cosmos DB İstemcisi arasında bağlantı paylaşımı kullanmanızı öneririz. Aynı JVM'de birden çok Azure Cosmos DB İstemcisi örneğiniz olduğunda birden çok Azure Cosmos DB hesabıyla etkileşimde bulunursanız, bunu etkinleştirmek Azure Cosmos DB İstemcisi örnekleri arasında mümkünse Doğrudan modda bağlantı paylaşımına olanak tanır. Bu seçeneği ayarlarken, ilk örneklenmiş istemcinin bağlantı yapılandırmasının (yuva zaman aşımı yapılandırması, boşta kalma zaman aşımı yapılandırması gibi) diğer tüm istemci örnekleri için kullanılacağını lütfen unutmayın.

Sık erişimli bölüm anahtarı

Azure Cosmos DB genel olarak sağlanan aktarım hızını fiziksel bölümler arasında eşit dağıtır. Sık erişimli bir bölüm söz konusu olduğunda, fiziksel bölümdeki bir veya birden fazla mantıksal bölüm 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 az olacaktır, ancak sık erişimli mantıksal bölüm anahtarına yönelik isteklerde azaltmayı (429s) görmeye devam edersiniz. İş yükünün sık erişimli bir bölümle karşılaşıp karşılaşmadiğini görmek için Normalleştirilmiş RU Tüketimi ölçümünü kullanın.

Çözüm:

İ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.

Çözüm:

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.

Çözüm:

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

Hata oranı Azure Cosmos DB SLA'sı içinde

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. Aynı öğeyi oluşturma için yeniden göndermek çakışma özel durumu oluşmasına neden olur. Kullanıcı uygulamaları iş mantığı, çakışmaları işlemek için özel bir mantığa sahip olabilir ve bu da var olan bir öğenin belirsizliğinden ve oluşturma yeniden denemesinden kaynaklanan çakışmalardan kaynaklanabilir.

Hata oranı Azure Cosmos DB SLA'sını ihlal ediyor

Azure Desteği'ne başvurun.

Sonraki adımlar