Share via

Azure depolama hesaplarında performans sorunlarını giderme

  • Makale

Bu makale, davranıştaki beklenmeyen değişiklikleri (normalden daha yavaş yanıt süreleri gibi) araştırmanıza yardımcı olur. Davranıştaki 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:

İzleme performansı

Depolama hizmetlerinin performansını izlemek için aşağıdaki ölçümleri kullanabilirsiniz:

  • SuccessE2ELatency ve SuccessServerLatency ölçümleri, depolama hizmetinin veya API işlem türünün istekleri işlemek için aldığı ortalama süreyi gösterir. SuccessE2ELatency , isteğin işlenmesi için geçen süreye ek olarak isteği okumak ve yanıtı göndermek için geçen süreyi de içeren uçtan uca gecikme süresi ölçüsüdür (bu nedenle, istek depolama hizmetine ulaştığında ağ gecikme süresini içerir). SuccessServerLatency yalnızca işlem süresinin bir ölçüsüdür ve bu nedenle istemciyle iletişim kurmayla ilgili ağ gecikme süresini dışlar.

  • Çıkış ve Giriş ölçümleri, depolama hizmetinize veya belirli bir API işlem türü aracılığıyla gelen ve giden toplam veri miktarını bayt cinsinden gösterir.

  • İşlemler ölçümü, API işleminin depolama hizmetinin aldığı toplam istek sayısını gösterir. İşlemler , depolama hizmetinin aldığı toplam istek sayısıdır.

Bu değerlerden herhangi birinde beklenmeyen değişiklikleri izleyebilirsiniz. Bu değişiklikler daha fazla araştırma gerektiren bir sorunu gösterebilir.

Azure portal, bu hizmetin performans ölçümlerinden herhangi biri belirttiğiniz eşiğin altına düştüğünde veya aştığında sizi bilgilendiren uyarı kuralları ekleyebilirsiniz.

Performans sorunlarını tanılama

Bir uygulamanın performansı, özellikle kullanıcı açısından öznel olabilir. Bu nedenle, performans sorununun nerede olabileceğini belirlemenize yardımcı olmak için temel ölçümlerin kullanılabilir olması önemlidir. İstemci uygulaması açısından bir Azure depolama hizmetinin performansını birçok faktör etkileyebilir. Bu faktörler depolama hizmetinde, istemcide veya ağ altyapısında çalışabilir. Bu nedenle, performans sorununun kaynağını belirlemeye yönelik bir stratejiye sahip olmak önemlidir.

Ölçümlerden performans sorununun nedeninin olası konumunu belirledikten sonra, sorunu daha fazla tanılamak ve gidermek için ayrıntılı bilgileri bulmak için günlük dosyalarını kullanabilirsiniz.

Ölçümler yüksek SuccessE2ELatency ve düşük SuccessServerLatency gösteriyor

Bazı durumlarda SuccessE2ELatency değerinin SuccessServerLatency değerinden daha yüksek olduğunu fark edebilirsiniz. Depolama hizmeti yalnızca başarılı istekler için SuccessE2ELatency ölçümünü hesaplar ve SuccessServerLatency'in aksine, istemcinin verileri göndermek ve depolama hizmetinden onay almak için aldığı süreyi içerir. Bu nedenle SuccessE2ELatency ile SuccessServerLatency arasındaki fark, istemci uygulamasının yanıt verme hızının yavaş olmasından veya ağdaki koşullardan kaynaklanıyor olabilir.

Not

Depolama Günlüğü günlük verilerinde tek tek depolama işlemleri için E2ELatency ve ServerLatency'ı da görüntüleyebilirsiniz.

İstemci performansı sorunlarını araştırma

İstemcinin yavaş yanıt vermesinin olası nedenleri arasında kullanılabilir bağlantı veya iş parçacıklarının sınırlı olması veya CPU, bellek veya ağ bant genişliği gibi kaynakların yetersiz olması sayılabilir. İstemci kodunu daha verimli olacak şekilde değiştirerek (örneğin, depolama hizmetine zaman uyumsuz çağrılar kullanarak) veya daha fazla çekirdek ve daha fazla belleğe sahip daha büyük bir Sanal Makine kullanarak sorunu çözebilirsiniz.

Tablo ve kuyruk hizmetleri için Nagle algoritması, SuccessServerLatency ile karşılaştırıldığında yüksek SuccessE2ELatency'a da neden olabilir. Daha fazla bilgi için Nagle Algoritması Küçük İsteklere Karşı Kolay Değil gönderisine bakın. Ad alanında sınıfını kullanarak kodda Nagle algoritmasını ServicePointManagerSystem.Net devre dışı bırakabilirsiniz. Zaten açık olan bağlantıları etkilemediğinden, uygulamanızdaki tablo veya kuyruk hizmetlerine herhangi bir çağrı yapmadan önce bunu yapmalısınız. Aşağıdaki örnek, çalışan rolündeki Application_Start yönteminden gelir:

var connectionString = Constants.connectionString;
QueueServiceClient queueServiceClient = new QueueServiceClient(connectionString);
ServicePoint queueServicePoint = ServicePointManager.FindServicePoint(queueServiceClient.Uri);
queueServicePoint.UseNagleAlgorithm = false;

İstemci uygulamanızın kaç istek gönderdiğini görmek için istemci tarafı günlüklerini denetlemeniz ve istemcinizde CPU, .NET çöp toplama, ağ kullanımı veya bellek gibi genel .NET ile ilgili performans sorunlarını denetlemeniz gerekir. .NET istemci uygulamalarında sorun gidermeye yönelik bir başlangıç noktası olarak bkz. Hata Ayıklama, İzleme ve Profil Oluşturma.

Ağ gecikmesi sorunlarını araştırma

Genellikle, ağın neden olduğu uçtan uca yüksek gecikme süresi geçici koşullardan kaynaklanır. Wireshark gibi araçları kullanarak bırakılan paketler gibi hem geçici hem de kalıcı ağ sorunlarını araştırabilirsiniz.

Ölçümler düşük SuccessE2ELatency ve düşük SuccessServerLatency gösteriyor ancak istemcide yüksek gecikme süresi yaşanıyor

Bu senaryoda, en olası neden depolama isteğinin depolama hizmetine ulaşmasındaki gecikmedir. İstemciden gelen isteklerin neden blob hizmetine iletilmiyor olduğunu araştırmanız gerekir.

İstemcinin istekleri göndermeyi geciktirmesinin olası nedenlerinden biri, sınırlı sayıda kullanılabilir bağlantı veya iş parçacığı olmasıdır.

Ayrıca, istemcinin birden çok yeniden deneme yapıp yapmadığını denetleyin ve bunun nedenini araştırın. İstemcinin birden çok yeniden deneme yapıp yapmadığını belirlemek için şunları yapabilirsiniz:

  • Günlükleri inceleyin. Birden çok yeniden deneme gerçekleştiriliyorsa, aynı istemci isteği kimliklerine sahip birden çok işlem görürsünüz.

  • İstemci günlüklerini inceleyin. Ayrıntılı günlük kaydı, yeniden denemenin gerçekleştiğini gösterir.

  • Kodunuzun hatalarını ayıklayın ve istekle ilişkili nesnenin OperationContext özelliklerini denetleyin. İşlem yeniden denendiyse özelliği RequestResults birden çok benzersiz istek içerir. Ayrıca her isteğin başlangıç ve bitiş saatlerini de de kontrol edebilirsiniz.

İstemcide sorun yoksa paket kaybı gibi olası ağ sorunlarını araştırmanız gerekir. Ağ sorunlarını araştırmak için Wireshark gibi araçları kullanabilirsiniz.

Ölçümler yüksek SuccessServerLatency gösteriyor

Blob indirme istekleri için yüksek SuccessServerLatency olması durumunda, aynı blob (veya blob kümesi) için yinelenen istekler olup olmadığını görmek için Depolama günlüklerini kullanmanız gerekir. Blob karşıya yükleme isteklerinde istemcinin hangi blok boyutunu kullandığını araştırmanız gerekir (örneğin, okumalar 64 K'den küçük öbekler içinde olmadığı sürece 64 K'den küçük bloklar ek yüklere neden olabilir) ve birden çok istemci blokları paralel olarak aynı bloba yüklüyorsa. Saniye başına ölçeklenebilirlik hedeflerinin aşılmasıyla sonuçlanır istek sayısındaki ani artışlar için dakika başına ölçümleri de denetlemeniz gerekir.

Aynı blob veya blob kümesi için yinelenen istekler olduğunda blob indirme istekleri için yüksek SuccessServerLatency görüyorsanız bu blobları Azure Cache veya Azure Content Delivery Network (CDN) kullanarak önbelleğe almayı göz önünde bulundurun. Karşıya yükleme istekleri için daha büyük bir blok boyutu kullanarak aktarım hızını geliştirebilirsiniz. Tablolara yönelik sorgular için, aynı sorgu işlemlerini gerçekleştiren ve verilerin sık değişmediği istemcilerde istemci tarafı önbelleğe alma da uygulanabilir.

Yüksek SuccessServerLatency değerleri, tarama işlemleriyle sonuçlanan veya ekleme/önceden eklenen anti-deseni izleyen kötü tasarlanmış tabloların veya sorguların belirtisi de olabilir.

Not

Microsoft Azure Depolama Performans ve Ölçeklenebilirlik Denetim Listesi'nden kapsamlı bir performans denetim listesi bulabilirsiniz.

Kuyrukta ileti tesliminde beklenmeyen gecikmelerle karşılaşıyorsunuz

Uygulamanın kuyruğa ileti eklemesi ile kuyruktan okunmaya uygun hale gelmesi arasında bir gecikmeyle karşılaşıyorsanız, sorunu tanılamak için aşağıdaki adımları izleyin:

  • Uygulamanın iletileri kuyruğa başarıyla eklediğini doğrulayın. Uygulamanın başarılı olmadan önce yöntemi birkaç kez yeniden denemediğini AddMessage denetleyin.

  • İletiyi kuyruğa ekleyen çalışan rolü ile iletiyi kuyruktan okuyan çalışan rolü arasında saat dengesizliği olmadığını doğrulayın. Saat dengesizliği, işlemede gecikme varmış gibi görünmesini sağlar.

  • Kuyruktan iletileri okuyan çalışan rolünün başarısız olup olmadığını denetleyin. Bir kuyruk istemcisi yöntemini çağırır GetMessage ancak bir bildirimle yanıt vermezse, süre dolana kadar invisibilityTimeout ileti kuyrukta görünmez durumda kalır. Bu noktada, ileti yeniden işlenmek üzere kullanılabilir hale gelir.

  • Kuyruk uzunluğunun zaman içinde artıp artmadığını denetleyin. Diğer çalışanların kuyruğa yerleştirmiş olduğu tüm iletileri işlemek için yeterli çalışan yoksa bu durum oluşabilir. Ayrıca silme isteklerinin başarısız olup olmadığını görmek için ölçümleri denetleyin ve iletilerin sıralamasını kaldırın; bu da iletiyi silme girişimlerinin tekrar tekrar başarısız olduğunu gösterebilir.

  • Beklenenden daha uzun bir süre boyunca beklenenden daha uzun E2ELatency ve ServerLatency değerlerine sahip tüm kuyruk işlemleri için Depolama günlüklerini inceleyin.

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.