Azure depolama hesaplarındaki kullanılabilirlik sorunlarını giderme

  • Makale

Bu makale, kullanılabilirlik değişiklikleri (başarısız isteklerin sayısı gibi) araştırmanıza yardımcı olur. Kullanılabilirlikteki bu değişiklikler genellikle Azure İzleyici'deki depolama ölçümleri izlenerek tanımlanabilir. Azure İzleyici'de ölçümleri ve günlükleri kullanma hakkında genel bilgi için aşağıdaki makalelere bakın:

Kullanılabilirliği izleme

Kullanılabilirlik ölçümünün değerini izleyerek depolama hesabınızdaki depolama hizmetlerinin kullanılabilirliğini izlemeniz gerekir. Kullanılabilirlik ölçümü bir yüzde değeri içerir. Toplam faturalanabilir istek değeri alınıp beklenmeyen hatalar oluşturan istekler de dahil olmak üzere geçerli istek sayısına bölünerek hesaplanır.

%100'den küçük bir değer bazı depolama isteklerinin başarısız olduğunu gösterir. ServerTimeoutError gibi hata türleri için ResponseType boyutunu inceleyerek neden başarısız olduklarını görebilirsiniz. Hizmet bölümleri daha iyi yük dengeleme isteklerine taşırken geçici sunucu zaman aşımları gibi nedenlerle Kullanılabilirlik'in geçici olarak %100'in altına düştüğünü görmeyi beklemelisiniz; istemci uygulamanızdaki yeniden deneme mantığı bu aralıklı koşulları işlemelidir.

Bir hizmetin kullanılabilirliği belirttiğiniz eşiğin altına düşerse sizi uyarmak için Azure İzleyici'deki özellikleri kullanabilirsiniz.

Ölçümler azaltma hatalarında artış gösteriyor

Bir depolama hizmetinin ölçeklenebilirlik hedeflerini aştığınızda azaltma hataları oluşur. Depolama hizmeti, tek bir istemcinin veya kiracının hizmeti başkalarının pahasına kullanabilmesini sağlamak için kısıtlar. Daha fazla bilgi için depolama hesapları için ölçeklenebilirlik hedefleri ve depolama hesapları içindeki bölümler için performans hedefleri hakkında ayrıntılı bilgi için bkz. Standart depolama hesapları için ölçeklenebilirlik ve performans hedefleri.

ResponseType boyutunun ClientThrottlingError veya ServerBusyError değeri azaltma hatasıyla başarısız olan isteklerin yüzdesinde bir artış gösteriyorsa, iki senaryodan birini araştırmanız gerekir:

  • PercentThrottlingError'da geçici artış
  • PercentThrottlingError hatasında kalıcı artış

Azaltma hatalarındaki artış genellikle depolama isteklerinin sayısındaki artışla veya uygulamanızın yük testini ilk kez yaptığınızda gerçekleşir. Bu, istemcide depolama işlemlerinden "503 Sunucu Meşgul" veya "500 İşlem Zaman Aşımı" HTTP durum iletileri olarak da kendini gösterebilir.

Azaltma hatalarında geçici artış

Uygulama için yüksek etkinlik dönemleriyle çakışan azaltma hatalarında ani artışlar görüyorsanız, istemcinizdeki yeniden denemeler için üstel (doğrusal değil) bir geri çekilme stratejisi uygularsınız. Geri alma yeniden denemeleri, bölümdeki anında yükü azaltır ve uygulamanızın trafikteki ani artışları düzeltmesine yardımcı olur. Depolama İstemci Kitaplığı'nı kullanarak yeniden deneme ilkelerini uygulama hakkında daha fazla bilgi için retryOptions.MaxRetries özelliğine bakın.

Not

Uygulama için yüksek etkinlik dönemleriyle çakışmayan azaltma hatalarında ani artışlar da görebilirsiniz. Bunun en olası nedeni depolama hizmetinin yük dengelemeyi geliştirmek için bölümleri taşımasıdır.

Azaltma hatalarında kalıcı artış

İşlem birimlerinizde kalıcı bir artış sonrasında azaltma hataları için tutarlı olarak yüksek bir değer görüyorsanız veya uygulamanızda ilk yük testlerinizi yapıyorsanız, uygulamanızın depolama bölümlerini nasıl kullandığını ve bir depolama hesabı için ölçeklenebilirlik hedeflerine yaklaşıp yaklaşmadığını değerlendirmeniz gerekir. Örneğin, bir kuyrukta azaltma hataları görüyorsanız (tek bir bölüm olarak sayılır), işlemleri birden çok bölüme yaymak için ek kuyruklar kullanmayı göz önünde bulundurabilirsiniz. Tabloda azaltma hataları görüyorsanız, daha geniş bir bölüm anahtarı değeri aralığı kullanarak işlemlerinizi birden çok bölüme yaymak için farklı bir bölümleme düzeni kullanmayı göz önünde bulundurun. Bu sorunun yaygın nedenlerinden biri, bölüm anahtarı olarak tarihi seçtiğiniz ve belirli bir gündeki tüm verilerin tek bir bölüme yazıldığı (yük altında yazma performans sorununa yol açabilen) ön ek/ekleme anti-desenidir. Farklı bir bölümleme tasarımı düşünün veya blob depolama kullanmanın daha iyi bir çözüm olup olmadığını değerlendirin. Ayrıca trafiğinizdeki ani artışlardan dolayı azaltmanın gerçekleşip gerçekleşmediğini denetleyin ve istek deseninizi düzeltmenin yollarını araştırın.

İşlemlerinizi birden çok bölüme dağıtırsanız, depolama hesabı için ayarlanan ölçeklenebilirlik sınırlarının farkında olmanız gerekir. Örneğin, her biri saniyede en fazla 2.000 1 KB ileti işleyen 10 kuyruk kullandıysanız depolama hesabı için saniyede toplam 20.000 ileti sınırında olursunuz. Saniyede 20.000'den fazla varlığı işlemeniz gerekiyorsa, birden çok depolama hesabı kullanmayı göz önünde bulundurun. Ayrıca, depolama hizmeti istemcilerinizi kısıtladığında isteklerinizin ve varlıklarınızın boyutunun etkilendiğini de unutmayın. Daha büyük istekleriniz ve varlıklarınız varsa, daha erken kısıtlanabilirsiniz.

Verimsiz sorgu tasarımı, tablo bölümleri için ölçeklenebilirlik sınırlarına ulaşmanıza da neden olabilir. Örneğin, bir bölümdeki varlıkların yalnızca yüzde birini seçen ancak bir bölümdeki tüm varlıkları tarayan filtreye sahip bir sorgunun her varlığa erişmesi gerekir. Okunan her varlık, bu bölümdeki toplam işlem sayısına doğru sayılır. Bu nedenle, ölçeklenebilirlik hedeflerine kolayca ulaşabilirsiniz.

Not

Performans testinizde uygulamanızdaki verimsiz sorgu tasarımları gösterilmelidir.

Ölçümler zaman aşımı hatalarında artış gösteriyor

ResponseType boyutu ServerTimeoutError veya ClientTimeout'a eşit olduğunda zaman aşımı hataları oluşur.

Ölçümleriniz, depolama hizmetlerinizden biri için zaman aşımı hatalarında artış gösteriyor. Aynı zamanda istemci, depolama işlemlerinden yüksek hacimli "500 İşlem Zaman Aşımı" HTTP durum iletisi alır.

Not

Depolama hizmeti bir bölümü yeni bir sunucuya taşıyarak isteklerin yükünü dengelediğinden geçici olarak zaman aşımı hataları görebilirsiniz.

Sunucu zaman aşımları (ServerTimeOutError) sunucudaki bir hatadan kaynaklanır. sunucudaki bir işlem istemci tarafından belirtilen zaman aşımını aştığından istemci zaman aşımları (ClientTimeout) gerçekleşir. Örneğin, Depolama İstemci kitaplığını kullanan bir istemci bir işlem için zaman aşımı ayarlayabilir.

Sunucu zaman aşımları, daha fazla araştırma gerektiren depolama hizmetiyle ilgili bir sorun olduğunu gösterir. Hizmetin ölçeklenebilirlik sınırlarına ulaşıp ulaşılmadığını görmek ve trafikte bu soruna neden olabilecek ani artışları belirlemek için ölçümleri kullanabilirsiniz. Sorun aralıklı olarak oluşuyorsa, hizmetteki yük dengeleme etkinliğinden kaynaklanıyor olabilir. Sorun kalıcıysa ve uygulamanız hizmetin ölçeklenebilirlik sınırlarına ulaşıyorsa bir destek sorunu oluşturmalısınız. İstemci zaman aşımları için, zaman aşımının istemcide uygun bir değere ayarlanıp ayarlanmadığını belirlemeniz ve istemcide ayarlanan zaman aşımı değerini değiştirmeniz veya depolama hizmetindeki işlemlerin performansını nasıl geliştirebileceğinizi araştırmanız gerekir( örneğin, tablo sorgularınızı iyileştirerek veya iletilerinizin boyutunu azaltarak).

Ölçümler ağ hatalarında artış gösteriyor

ResponseType boyutu NetworkError'a eşit olduğunda ağ hataları oluşur. Bunlar, bir depolama hizmeti istemci depolama isteğinde bulunurken bir ağ hatası algıladığında oluşur.

Bu hatanın en yaygın nedeni, depolama hizmetinde zaman aşımı süresi dolmadan önce istemcinin bağlantısının kesilmesidir. İstemcinin depolama hizmetiyle bağlantısının neden ve ne zaman kesiliyor olduğunu anlamak için istemcinizdeki kodu araştırın. İstemciden gelen ağ bağlantısı sorunlarını araştırmak için üçüncü taraf ağ çözümleme araçlarını da kullanabilirsiniz.

Ayrıca bkz.

Yardım için bize ulaşın

Sorularınız veya yardıma ihtiyacınız varsa bir destek isteği oluşturun veya Azure topluluk desteği isteyin. Ürün geri bildirimini Azure geri bildirim topluluğuna da gönderebilirsiniz.