Not
Bu sayfaya erişim yetkilendirme gerektiriyor. Oturum açmayı veya dizinleri değiştirmeyi deneyebilirsiniz.
Bu sayfaya erişim yetkilendirme gerektiriyor. Dizinleri değiştirmeyi deneyebilirsiniz.
✔️ Şunlar için geçerlidir: Microsoft.Storage kaynak sağlayıcısıyla oluşturulan klasik SMB ve NFS dosya paylaşımları
✔️ Şunlar için geçerlidir: Microsoft.FileShares kaynak sağlayıcısıyla oluşturulan dosya paylaşımları
Azure Dosyalar çoğu uygulama ve kullanım örneği için performans gereksinimlerini karşılayabilir. Bu makalede, dosya paylaşımı performansını etkileyen farklı faktörler ve iş yükünüz için Azure Dosyalar performansını iyileştirme açıklanmaktadır.
Depolama performansı sözlüğü
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. Azure Dosyalar belgelerinde "G/Ç" terimi, "operasyon" ve "işlem" terimleriyle birbirinin yerine kullanılabilir.
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 küçük boyutlardan 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 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 desenlerini temel alan bir medya katmanı seçme
Azure Dosyalar, performansı ve fiyatı dengelemek için kullanabileceğiniz iki depolama medya katmanı sağlar: SSD ve HDD. Dosya paylaşımı için medya katmanını depolama hesabı düzeyinde seçersiniz. Belirli bir medya katmanında depolama hesabı oluşturduktan sonra, yeni bir dosya paylaşımına el ile geçiş yapmadan diğer medya katmanına geçemezsiniz.
SSD ve HDD dosya paylaşımları arasında seçim yaptığınızda, Azure Dosyalar üzerinde çalıştırmayı planladığınız beklenen kullanım deseninin gereksinimlerini göz önünde bulundurun. Büyük miktarlarda IOPS, yüksek veri aktarım hızı veya düşük gecikme süresine ihtiyacınız varsa SSD dosya paylaşımları'nı seçin.
Aşağıdaki tabloda SSD ve HDD dosya paylaşımları arasında beklenen performans hedefleri özetlenmektedir. Ayrıntılar için bkz Azure Dosyalar ölçeklenebilirlik ve performans hedefleri.
| Kullanım düzeni gereksinimleri | SSD | HDD |
|---|---|---|
| Yazma gecikme süresi (tek basamaklı milisaniye) | Evet | Evet |
| Okuma gecikme süresi (tek basamaklı milisaniye) | Evet | Hayır |
SSD dosya paylaşımları, paylaşım boyutuna göre aşağıdaki performans profilini garanti eden bir sağlama modeli kullanır. Daha fazla bilgi için sağlanan v1 modeline bakın.
Performans için en iyi yöntemler
İ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.
Gecikme süresi duyarlılığı: Okuma gecikmesine duyarlı olan ve son kullanıcılar için yüksek görünürlüğe sahip iş yükleri, hem okuma hem de yazma işlemleri için tek milisaniyelik gecikme süresi (küçük G/Ç boyutu için 2 ms'den az) sağlayabilen SSD dosya paylaşımları için daha uygundur.
IOPS ve aktarım hızı gereksinimleri: SSD dosya paylaşımları, HDD 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 HDD dosya paylaşımlarının üst performans sınırlarına ulaşma olasılığı, uzun süre çalışan ve sık gerçekleşen iş yükleriyle karşılaştırıldığında daha azdır. SSD dosya paylaşımlarında iş yükü süresi sağlanan depolama, IOPS ve aktarım hızına göre kullanılacak doğru performans profilinin belirlenmesine yardımcı olur. Genellikle yanıltıcı olan performans testlerinin yalnızca birkaç dakika boyunca çalıştırılması yaygın bir hatadır. Performansın gerçekçi bir görünümü elde etmek için, yeterince yüksek frekans ve sürede test yaptığınızdan emin olun.
İş 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, SSD dosya paylaşımları HDD 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ı: Çok sayıda dosyaya karşı okuma işlemleri gerçekleştiren iş yükleri gibi meta veri ağır iş yükleri, SSD dosya paylaşımları için daha uygundur. Daha fazla bilgi için bkz: Meta veriler veya ad alanı yoğun iş yükü.
Bölgesel yerleştirme: Depolama hesabınızın bulunduğu belirli kullanılabilirlik alanını seçmek için bölgesel yerleştirmeyi kullanın. Bu özellik, VM'lerinizi depolama alanınızla aynı kullanılabilirlik alanına yerleştirmenize olanak tanır ve bu da gecikme süresini yüzde 30'a kadar azaltabilir. Bu özellik şu anda yalnızca desteklenen bölgelerde yerel olarak yedekli depolama (LRS) kullanan SSD depolama hesapları için kullanılabilir.
Gecikme süresi
Gecikmeyi düşündüğünüzde, önce Azure Dosyalar gecikme süresini nasıl belirlediğini anlayın. 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 geçişte ne kadar zaman harcadığını göstererek istemci tarafı gecikme süresini ve ağ sorunlarını belirlemenize 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 içinde gidiş dönüş süresidir. Bu ölçüm 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 gecikmesi düşük gecikme gösteriyorsa ve uçtan uca gecikme istekler için çok yüksek gecikme gösteriyorsa, tüm süre istemciye ve istemciden iletim sırasında geçer, Azure Dosyalar hizmetinde geçmez.
Ayrıca, diyagramda gösterildiği gibi hizmetten ne kadar uzaktaysanız gecikme süresi o kadar yavaştır ve herhangi bir bulut hizmetiyle performans ölçek sınırlarına ulaşmak o kadar zordur. Bu durum özellikle şirket içinden Azure Dosyalar erişilirken geçerlidir. Azure 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.
Tavsiye
Ş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. Az veya yanlış yönlendirilmiş ExpressRoute bağlantı hatları veya VPN ağ geçitleri, Azure Dosyalar üzerinde çalışan iş yüklerini önemli ölçüde yavaşlatabilir.
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) geliştikçe, daha yüksek kuyruk derinliğini destekleyecek şekilde de gelişti. 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 dağıtılmış bir dosya hizmeti olduğundan ve iş yüklerini büyük ölçekte çalıştırmak, yüksek kuyruk derinliğine sahip iş yüklerini derlemek ve test etmek için tasarlanmıştır.
Yüksek kuyruk derinliğine birkaç farklı yolla ulaşabilirsiniz. İş 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 birleşimler gösterilmektedir. En uygun kuyruk derinliği olan 64'ü aşabilirsiniz ancak bu önerilmez. 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.
| Müşteriler | Dosyalar | Thread'ler | 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 | 32 |
Tavsiye
En yüksek performans sınırlarına ulaşmak için, iş yükünüzün veya kıyaslama testinizin birden çok dosya kullanan ve çok iş parçacıklı bir yapıda olduğundan emin olun.
Tek iş parçacığı ve çok iş parçacıklı uygulamalar karşılaştırması
Azure Dosyalar, çok iş parçacıklı uygulamalarla en iyi şekilde çalışır. Çok iş parçacıklılığın bir iş yükü üzerindeki performans etkisini anlamanın en kolay yolu, senaryoyu G/Ç açısından adım adım incelemektir. Aşağıdaki örnekte, 10.000 küçük dosyayı mümkün olan en kısa sürede Azure dosya paylaşımına kopyalaması gereken bir iş yükünüz vardır.
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çası 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ürer. Tek iş parçacıklı bir uygulama 10.000 dosyayı bir Azure dosya paylaşımına taşımak isterse, her dosya sırayla tek tek taşındığından bu işlem 140.000 ms (14 ms × 10.000) veya 140 saniyeye çevrilir. Önceki bölümde açıklandığı gibi, her isteğin hizmet verme süresi öncelikli olarak işlem ve depolama alanının birbirine ne kadar yakın olduğuna göre belirlenir.
Bir yerine sekiz iş parçacığı kullanarak, önceki iş yükünü 140.000 ms'den (140 saniye) 17.500 ms'ye (17,5 saniye) düşürebilirsiniz. Aşağıdaki tabloda gösterildiği gibi, aynı anda bir dosya yerine sekiz dosyayı paralel olarak taşıdığınızda, 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çası 1 | 3 ms | 2 ms | 2 ms | 2 ms | 2 ms | 3 ms | 14 ms |
| Başlık 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 |