Azure dosya paylaşımı performansını anlama ve iyileştirme
Azure Dosyalar çoğu uygulama ve kullanım örneği için 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.
İşlem hızı
Aktarım hızı, saniyede depolama alanından okunan veya yazılan bit sayısını ölçer ve saniye başına 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 gecikme süresi. 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 yüksek 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 arasında sorunsuz bir şekilde geçiş yapabileceğiniz birkaç depolama katmanı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 yüksek 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 özetlenmektedir. Ayrıntılar için bkz. ölçeklenebilirlik ve performans hedefleri Azure Dosyalar.
| Kullanım düzeni gereksinimleri | Standart | Premium |
|---|---|---|
| Yazma gecikme süresi (tek basamaklı milisaniye) | Yes | Yes |
| Okuma gecikme süresi (tek basamaklı milisaniye) | Hayır | Evet |
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ılan 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 | En fazla 30.720 | 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 bir 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 düzenlerini belirlemek için depolama yöneticinize veya uygulama geliştiricinize başvurun.
Gecikme duyarlılığı: Kullanıcılar dosyaları açıyor mu veya Azure Dosyalar üzerinde çalışan sanal masaüstleriyle etkileşim mi açıyor? Bunlar, okuma gecikmesine duyarlı olan ve son kullanıcılar için yüksek görünürlüğe sahip iş yüklerine örnektir. Bu iş yükü türleri, hem okuma hem de yazma işlemleri< için tek milisaniyelik gecikme süresi (küçük G/Ç boyutu için 2 ms) 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 kredi 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 düşürü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 sıklıkta ve sürelerde test etmeye dikkat edin.
İş yükü paralelleştirme: Aynı istemcideki birden çok iş parçacığı, işlem veya uygulama örneği gibi işlemleri paralel olarak 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 dosyaya karşı 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 gecikme süresinin 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üresi ve/veya ağ sorunlarını belirlemeye yardımcı olabilir.
Uçtan uca gecikme süresi (SuccessE2ELatency), bir işlemin istemciden, ağ genelinden Azure Dosyalar hizmetine ve istemciye geri dönmesi için geçen toplam gidiş dönüş süresidir.
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 gecikme süresini hizmet gecikme süresiyle (bu durumda Azure Dosyalar performans) karıştırmak yaygın bir durumdı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şilirken 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 veya yanlış yönlendirilmiş ExpressRoute bağlantı hattı veya VPN ağ geçidi tarafından yavaşlatılabilir.
Kuyruk derinliği
Kuyruk derinliği, bir depolama kaynağının hizmet olarak kullanabileceğ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ğine örnektir. 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ğine ulaşabilir. 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 (istemciler * dosyalar * iş parçacıkları = kuyruk derinliği) çarpın.
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 | Kategori 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, senaryoyu G/Ç'ye göre izleyerek geçmektir. Aşağıdaki örnekte, 10.000 küçük dosyayı bir Azure dosya paylaşımına veya bir Azure dosya paylaşımından mümkün olan en kısa sürede kopyalaması gereken bir iş yüküne sahibiz.
Bu tablo, 4 KiB blok boyutunda yazılan 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 (14 ms * 10.000) veya 140 saniyeye dönüşür çünkü her dosya sırayla tek tek taşınır. Önceki bölümde açıklandığı gibi, her isteğin hizmet verme süresinin öncelikle işlem ve depolama alanının birbirine ne kadar yakın olduğuna göre belirlendiğini unutmayın.
Yukarıdaki iş yükü, bir yerine sekiz iş parçacığı kullanılarak 140.000 ms'den (140 saniye) 17.500 ms'ye (17,5 saniye) düşürülebilir. Aşağıdaki tabloda gösterildiği gibi, aynı anda bir dosya yerine sekiz dosyayı paralel olarak taşırken aynı miktarda veriyi %87,5 daha kısa sürede 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 |