Aracılığıyla paylaş

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

  • Makale

Bu makale, kullanılabilirlik (başarısız istek sayısı gibi) değişikliklerini 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örmeniz gerekir; istemci uygulamanızdaki yeniden deneme mantığı bu aralıklı koşulları işlemelidir. Kullanılabilirlik ölçümü yalnızca hesapta işlemler gerçekleştiği zaman aralıkları için kullanılabilir.

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

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ında artış genellikle depolama isteği sayısındaki artışla veya uygulamanızın yük testini ilk kez gerçekleştirdiğinizde 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 olmayan) bir geri alma 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 veya uygulamanızda ilk yük testlerinizi gerçekleştirirken azaltma hataları için sürekli olarak yüksek bir değer görüyorsanız, uygulamanızın depolama bölümlerini nasıl kullandığını ve depolama hesabının ö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 bulundurun. 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 neden olabilen) ö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ı taraan 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 testiniz uygulamanızdaki verimsiz sorgu tasarımlarını ortaya çıkarmalıdır.

Ö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ış olduğunu 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 erişip aşmadığınızı görmek ve trafikte bu soruna neden olabilecek ani artışları belirlemek için ölçümleri kullanabilirsiniz. Sorun aralıklıysa, hizmetteki yük dengeleme etkinliğinden kaynaklanıyor olabilir. Sorun kalıcıysa ve uygulamanızın hizmetin ölçeklenebilirlik sınırlarına erişmesi nedeniyle değilse 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 küçülterek.

Ö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 bizimle iletişim kurun

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