performansı Azure Dosyalar anlama
Azure Dosyalar çoğu uygulama ve kullanım örneğinin performans gereksinimlerini karşılayabilir. Bu makalede, dosya paylaşımı performansını etkileyebilecek farklı faktörler ve iş yükünüz için Azure dosya paylaşımlarının performansını iyileştirme adımları açıklanmaktadır.
Şunlara uygulanır
| Dosya paylaşımı türü | SMB | NFS |
|---|---|---|
| Standart dosya paylaşımları (GPv2), LRS/ZRS |  |
 |
| Standart dosya paylaşımları (GPv2), GRS/GZRS | |
|
| Premium dosya paylaşımları (filestorage), LRS/ZRS | |
|
Sözlük
Bu makaleyi okumadan önce depolama performansıyla ilgili bazı önemli terimleri anlamak yararlı olacaktır:
Saniye başına GÇ işlemleri (IOPS)
IOPS veya saniye başına giriş/çıkış işlemleri, saniye başına dosya sistemi işlemlerinin sayısını ölçer. "GÇ" terimi, Azure Dosyalar belgelerindeki "işlem" ve "işlem" terimleriyle kesişebilir.
G/Ç boyutu
Bazen blok boyutu olarak da adlandırılan G/Ç boyutu, bir uygulamanın depolamada tek bir giriş/çıkış (G/Ç) işlemi gerçekleştirmek için kullandığı isteğin boyutudur. Uygulamaya bağlı olarak G/Ç boyutu 4 KiB gibi çok küçük boyutlardan çok daha büyük boyutlara kadar değişebilir. G/Ç boyutu, ulaşılabilir aktarım hızı açısından önemli bir rol oynar.
İşleme hızı
Aktarım hızı, saniyede depolama alanından okunan veya yazılan bit sayısını ölçer ve saniyede mebibayt (MiB/sn) cinsinden ölçülür. Aktarım hızını hesaplamak için IOPS'yi G/Ç boyutuyla çarpın. Örneğin, 10.000 IOPS * 1 MiB G/Ç boyutu = 10 GiB/sn, 10.000 IOPS * 4 KiB G/Ç boyutu = 38 MiB/sn.
Gecikme süresi
Gecikme, gecikme için eş anlamlıdır ve genellikle milisaniye (ms) cinsinden ölçülür. İki tür gecikme süresi vardır: uçtan uca gecikme süresi ve hizmet gecikmesi. Daha fazla bilgi için bkz . Gecikme süresi.
Kuyruk derinliği
Kuyruk derinliği, depolama kaynağının herhangi bir anda işleyebileceği bekleyen G/Ç isteklerinin sayısıdır. Daha fazla bilgi için bkz . Kuyruk derinliği.
Kullanım desenlerine göre performans katmanı seçme
Azure Dosyalar, verileri uygun performans ve fiyat düzeyinde depolamanıza olanak tanıyarak maliyetleri azaltmaya yardımcı olan bir dizi depolama katmanı sağlar. Azure Dosyalar en üst düzeyde iki performans katmanı sunar: standart ve premium. Standart dosya paylaşımları sabit disk sürücüleri (HDD) tarafından yedeklenen bir depolama sisteminde barındırılırken, premium dosya paylaşımları daha iyi performans için katı hal sürücüleri (SSD) tarafından desteklenir. Standart dosya paylaşımları, bekleyen depolama ve işlem fiyatlarını en üst düzeye çıkarmak için aralarında sorunsuz bir şekilde geçiş yapabileceğiniz çeşitli depolama katmanlarına (işlem için iyileştirilmiş, sık erişimli ve seyrek erişimli) sahiptir. Ancak, verilerinizi farklı depolama hesapları arasında fiziksel olarak geçirmeden standart ve premium katmanlar arasında geçiş yapamazsınız.
Standart ve premium dosya paylaşımları arasında seçim yaparken, Azure Dosyalar üzerinde çalıştırmayı planladığınız beklenen kullanım düzeninin gereksinimlerini anlamak önemlidir. Büyük miktarlarda IOPS, son derece hızlı veri aktarım hızları veya çok düşük gecikme süresine ihtiyacınız varsa premium Azure dosya paylaşımları'nı seçmeniz gerekir.
Aşağıdaki tabloda standart ve premium arasında beklenen performans hedefleri özetlenmiştir. Ayrıntılar için bkz. ölçeklenebilirlik ve performans hedefleri Azure Dosyalar.
| Kullanım deseni gereksinimleri | Standart | Premium |
|---|---|---|
| Yazma gecikme süresi (tek basamaklı milisaniye) | Yes | Yes |
| Okuma gecikmesi (tek basamaklı milisaniye) | Hayır | Yes |
Premium dosya paylaşımları, paylaşım boyutuna göre aşağıdaki performans profilini garanti eden bir sağlama modeli sunar. Daha fazla bilgi için bkz . Sağlanan model. Dosya paylaşımınız için trafik temel IOPS'nin altında olduğunda ani artış kredileri bir ani artış demetinde birikir. Kazanılmış krediler daha sonra işlemler temel IOPS'yi aştığında ani artış sağlamak için kullanılır.
| Kapasite (GiB) | Temel IOPS | Seri IOPS | Ani krediler | Aktarım hızı (giriş + çıkış) |
|---|---|---|---|---|
| 100 | 3,100 | En fazla 10.000 | 24,840,000 | 110 MiB/sn |
| 500 | 3.500 | En fazla 10.000 | 23,400,000 | 150 MiB/sn |
| 1,024 | 4,024 | En fazla 10.000 | 21,513,600 | 203 MiB/sn |
| 5,120 | 8,120 | En fazla 15.360 | 26,064,000 | 613 MiB/sn |
| 10,240 | 13,240 | 30.720'ye kadar | 62,928,000 | 1.125 MiB/sn |
| 33,792 | 36,792 | En fazla 100.000 | 227,548,800 | 3.480 MiB/sn |
| 51,200 | 54,200 | En fazla 100.000 | 164,880,000 | 5.220 MiB/sn |
| 102,400 | 100.000 | En fazla 100.000 | 0 | 10.340 MiB/sn |
Performans denetim listesi
İster yeni ister mevcut iş yükü için performans gereksinimlerini değerlendirin, kullanım desenlerinizi anlamak öngörülebilir performans elde etmenize yardımcı olur. Aşağıdaki kullanım desenlerini belirlemek için depolama yöneticinize veya uygulama geliştiricinize danışın.
Gecikme duyarlılığı: Kullanıcılar dosyaları açıyor mu veya Azure Dosyalar üzerinde çalışan sanal masaüstleriyle etkileşim mi kuracak? Bunlar, okuma gecikmesine duyarlı olan ve son kullanıcılar için yüksek görünürlüğe sahip iş yüklerine örnek olarak verilebilir. Bu iş yükü türleri, hem okuma hem de yazma işlemleri< (küçük G/Ç boyutu için 2 ms) için tek milisaniyelik gecikme süresi sağlayabilen premium Azure dosya paylaşımları için daha uygundur.
IOPS ve aktarım hızı gereksinimleri: Premium dosya paylaşımları, standart dosya paylaşımlarından daha büyük IOPS ve aktarım hızı sınırlarını destekler. Daha fazla bilgi için bkz. dosya paylaşımı ölçek hedefleri .
İş yükü süresi ve sıklığı: Kısa (dakika) ve seyrek (saatlik) iş yüklerinin, uzun süre çalışan ve sık gerçekleşen iş yüklerine kıyasla standart dosya paylaşımlarının üst performans sınırlarına ulaşma olasılığı daha düşük olacaktır. Premium dosya paylaşımlarında iş yükü süresi, sağlama boyutuna göre kullanılacak doğru performans profilini belirlerken yararlıdır. İş yükünün ne kadar süreyle verim alması gerektiği ve temel IOPS'nin altında ne kadar zaman harcadığına bağlı olarak, yoğun zamanlarda iş yükünüzü tutarlı bir şekilde karşılamak için yeterli miktarda ani artış kredisi biriktirip toplamadığınızı belirleyebilirsiniz. Doğru bakiyeyi bulmak, dosya paylaşımının aşırı sağlanmasıyla karşılaştırıldığında maliyetleri azaltır. Yaygın bir hata, performans testlerini yalnızca birkaç dakika çalıştırmaktır ve bu genellikle yanıltıcıdır. Performansın gerçekçi bir görünümünü elde etmek için yeterince yüksek frekans ve süreyle test edin.
İş yükü paralelleştirme: Aynı istemcideki birden çok iş parçacığı, işlem veya uygulama örneği gibi paralel işlemler gerçekleştiren iş yükleri için premium dosya paylaşımları, standart dosya paylaşımlarına göre net bir avantaj sağlar: Çok Kanallı SMB. Daha fazla bilgi için bkz. SMB Azure dosya paylaşımı performansını geliştirme .
API işlemi dağıtımı: dosya açma/kapatma işlemleriyle iş yükü meta verileri ağır mı? Bu, çok sayıda dosyada okuma işlemleri gerçekleştiren iş yükleri için yaygındır. Bkz. Meta veriler veya ad alanı ağır iş yükü.
Gecikme süresi
Gecikmeyi düşünürken, önce Azure Dosyalar ile gecikmenin nasıl belirlendiğini anlamak önemlidir. En yaygın ölçümler, uçtan uca gecikme süresi ve hizmet gecikmesi ölçümleriyle ilişkili gecikme süresidir . Bu işlem ölçümlerini kullanmak, uygulama trafiğinizin istemciye ve istemciden aktarım sırasında ne kadar zaman harcadığını belirleyerek istemci tarafı gecikme süresini ve/veya ağ sorunlarını belirlemenize yardımcı olabilir.
Uçtan uca gecikme süresi (SuccessE2ELatency), bir işlemin istemciden, ağ üzerinden, Azure Dosyalar hizmetine ve istemciye geri dönüş için tam bir gidiş dönüş gerçekleştirmesi için geçen toplam süredir.
Hizmet Gecikme Süresi (SuccessServerLatency), bir işlemin yalnızca Azure Dosyalar hizmeti içinde gidiş dönüş süresidir. Bu, herhangi bir istemci veya ağ gecikme süresi içermez.
SuccessE2ELatency ile SuccessServerLatency değerleri arasındaki fark, ağ ve/veya istemcinin neden olduğu gecikme süresidir.
İstemci gecikmesini hizmet gecikme süresiyle (bu örnekte performans Azure Dosyalar) karıştırmak yaygındır. Örneğin, hizmet gecikme süresi düşük gecikme süresi bildiriyorsa ve uçtan uca istekler için çok yüksek gecikme süresi bildiriyorsa, bu, tüm zamanın Azure Dosyalar hizmetinde değil istemciye ve istemciden aktarımda harcandığını gösterir.
Ayrıca, diyagramda gösterildiği gibi hizmetten ne kadar uzaktaysanız gecikme süresi o kadar yavaş olur ve herhangi bir bulut hizmetiyle performans ölçek sınırlarına ulaşmak o kadar zor olur. Bu durum özellikle şirket içinden Azure Dosyalar erişirken geçerlidir. ExpressRoute gibi seçenekler şirket içi için ideal olsa da, yine de yalnızca aynı Azure bölgesinde çalışan bir uygulamanın (işlem + depolama) performansıyla eşleşmez.
İpucu
Şirket içi ile Azure arasındaki performansı test etmek için Azure'da VM kullanmak, Azure bağlantısının ağ özelliklerini temellendirmenin etkili ve pratik bir yoludur. Genellikle bir iş yükü, küçük boyutlu veya yanlış yönlendirilmiş ExpressRoute bağlantı hattı veya VPN ağ geçidi tarafından yavaşlatılabilir.
Kuyruk derinliği
Kuyruk derinliği, depolama kaynağının hizmet gösterebileceği bekleyen G/Ç isteklerinin sayısıdır. Depolama sistemleri tarafından kullanılan diskler HDD iş millerinden (IDE, SATA, SAS) katı hal cihazlarına (SSD, NVMe) dönüştükçe, daha yüksek kuyruk derinliğini destekleyecek şekilde de gelişmiştir. Büyük bir veri kümesindeki tek bir dosyayla seri olarak etkileşim kuran tek bir istemciden oluşan iş yükü, düşük kuyruk derinliği örneğidir. Buna karşılık, birden çok iş parçacığı ve birden çok dosya ile paralelliği destekleyen bir iş yükü kolayca yüksek kuyruk derinliği elde edebilir. Azure Dosyalar binlerce Azure küme düğümüne yayılan ve iş yüklerini büyük ölçekte çalıştıracak şekilde tasarlanmış dağıtılmış bir dosya hizmeti olduğundan, yüksek kuyruk derinliğine sahip iş yükleri oluşturmanızı ve test etmenizi öneririz.
Yüksek kuyruk derinliği istemciler, dosyalar ve iş parçacıklarıyla birlikte birkaç farklı yolla elde edilebilir. İş yükünüzün kuyruk derinliğini belirlemek için, istemci sayısını dosya sayısıyla iş parçacığı sayısıyla çarpın (istemciler * dosyalar * iş parçacıkları = kuyruk derinliği).
Aşağıdaki tabloda daha yüksek kuyruk derinliği elde etmek için kullanabileceğiniz çeşitli bileşimler gösterilmektedir. En uygun kuyruk derinliği olan 64'ü aşabilirsiniz ancak bunu önermeyiz. Bunu yaparsanız daha fazla performans kazancı görmezsiniz ve TCP doygunluğu nedeniyle gecikme süresini artırma riskiyle karşılaşırsınız.
| İstemciler | Dosyalar | İş Parçacıkları | Kuyruk derinliği |
|---|---|---|---|
| 1 | 1 | 1 | 1 |
| 1 | 1 | 2 | 2 |
| 1 | 2 | 2 | 4 |
| 2 | 2 | 2 | 8 |
| 2 | 2 | 4 | 16 |
| 2 | 4 | 4 | 32 |
| 1 | 8 | 8 | 64 |
| 4 | 4 | 2 | 64 |
İpucu
Üst performans sınırlarına ulaşmak için iş yükünüzün veya karşılaştırma testinizin birden çok dosyayla çok iş parçacıklı olduğundan emin olun.
Tek ve çok iş parçacıklı uygulamalar
Azure Dosyalar, çok iş parçacıklı uygulamalar için en uygun yöntemdir. Çoklu iş parçacığı oluşturmanın bir iş yükü üzerindeki performans etkisini anlamanın en kolay yolu, G/Ç'ye göre senaryoyu gözden geçirebilmektir. Aşağıdaki örnekte, Bir Azure dosya paylaşımına veya azure dosya paylaşımından mümkün olan en kısa sürede 10.000 küçük dosyayı kopyalaması gereken bir iş yüküne sahibiz.
Bu tablo, 4 KiB blok boyutunda yazan tek iş parçacıklı bir uygulamayı temel alarak Azure dosya paylaşımında tek bir 16 KiB dosyası oluşturmak için gereken süreyi (milisaniye olarak) ayırır.
| G/Ç işlemi | Oluştur | 4 KiB yazma | 4 KiB yazma | 4 KiB yazma | 4 KiB yazma | Kapat | Toplam |
|---|---|---|---|---|---|---|---|
| İş Parçacığı 1 | 3 ms | 2 ms | 2 ms | 2 ms | 2 ms | 3 ms | 14 ms |
Bu örnekte, altı işlemden tek bir 16 KiB dosyası oluşturmak yaklaşık 14 ms sürebilir. Tek iş parçacıklı bir uygulama 10.000 dosyayı Bir Azure dosya paylaşımına taşımak isterse, bu 140.000 ms 'ye (14 ms * 10.000) veya 140 saniyeye dönüşür çünkü her dosya sırayla birer birer taşınır. Önceki bölümde açıklandığı gibi, her isteğin hizmet verme zamanının öncelikli olarak işlem ve depolama alanının birbirine ne kadar yakın olduğuna göre belirlendiğini unutmayın.
Bir yerine sekiz iş parçacığı kullanıldığında yukarıdaki iş yükü 140.000 ms'den (140 saniye) 17.500 ms'ye (17,5 saniye) düşürülebilir. Aşağıdaki tabloda gösterildiği gibi, bir kerede bir dosya yerine sekiz dosyayı paralel olarak taşırken aynı miktarda veriyi %87,5 daha az zamanda taşıyabilirsiniz.
| G/Ç işlemi | Oluştur | 4 KiB yazma | 4 KiB yazma | 4 KiB yazma | 4 KiB yazma | Kapat | Toplam |
|---|---|---|---|---|---|---|---|
| İş Parçacığı 1 | 3 ms | 2 ms | 2 ms | 2 ms | 2 ms | 3 ms | 14 ms |
| İş Parçacığı 2 | 3 ms | 2 ms | 2 ms | 2 ms | 2 ms | 3 ms | 14 ms |
| İş Parçacığı 3 | 3 ms | 2 ms | 2 ms | 2 ms | 2 ms | 3 ms | 14 ms |
| İş Parçacığı 4 | 3 ms | 2 ms | 2 ms | 2 ms | 2 ms | 3 ms | 14 ms |
| İş Parçacığı 5 | 3 ms | 2 ms | 2 ms | 2 ms | 2 ms | 3 ms | 14 ms |
| İş Parçacığı 6 | 3 ms | 2 ms | 2 ms | 2 ms | 2 ms | 3 ms | 14 ms |
| İş Parçacığı 7 | 3 ms | 2 ms | 2 ms | 2 ms | 2 ms | 3 ms | 14 ms |
| İş Parçacığı 8 | 3 ms | 2 ms | 2 ms | 2 ms | 2 ms | 3 ms | 14 ms |