Aracılığıyla paylaş

Azure Dosyalar performans sorunlarını giderme

Not

Bu makalede başvuruda bulunan CentOS bir Linux dağıtımıdır ve Kullanım Süresi Sonuna (EOL) ulaşacaktır. Kullanımınızı göz önünde bulundurun ve buna göre planlayın. Daha fazla bilgi için bkz . CentOS Kullanım Süresi Sonu kılavuzu.

Bu makalede Azure dosya paylaşımı performansıyla ilgili yaygın sorunlar listelenir ve olası nedenler ve geçici çözümler sağlanır. Bu sorun giderme kılavuzundan en iyi şekilde yararlanmak için önce Performansı anlama Azure Dosyalar makalesini okumanızı öneririz.

Şunlara uygulanır

Dosya paylaşımı türü KOBİ Ağ Dosya Sistemi (NFS)
Standart dosya paylaşımları (GPv2), LRS/ZRS
Standart dosya paylaşımları (GPv2), GRS/GZRS
Premium dosya paylaşımları (filestorage), LRS/ZRS

Genel performans sorunlarını giderme

Öncelikle, performans sorunları yaşıyor olmanızın bazı yaygın nedenlerini eleyin.

Eski bir işletim sistemi çalıştırıyorsunuz

İstemci sanal makineniz (VM) Windows 8.1 veya Windows Server 2012 R2 ya da daha eski bir Linux dağıtımı veya çekirdeği çalıştırıyorsa, Azure dosya paylaşımlarına erişirken performans sorunlarıyla karşılaşabilirsiniz. İstemci işletim sisteminizi yükseltin veya aşağıdaki düzeltmeleri uygulayın.

Windows 8.1 ve Windows Server 2012 R2 ile ilgili dikkat edilmesi gerekenler

Windows 8.1 veya Windows Server 2012 R2 çalıştıran istemciler, G/Ç yoğunluklu iş yükleri için Azure dosya paylaşımlarına erişirken beklenenden daha uzun gecikme süresi görebilir. KB3114025 düzeltmesinin yüklü olduğundan emin olun. Bu düzeltme, create ve close handle'larının performansını artırır.

Düzeltmenin yüklenip yüklenmediğini denetlemek için aşağıdaki betiği çalıştırabilirsiniz:

reg query HKLM\SYSTEM\CurrentControlSet\Services\LanmanWorkstation\Parameters\Policies

Düzeltme yüklüyse aşağıdaki çıktı görüntülenir.

HKEY_Local_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanWorkstation\Parameters\Policies {96c345ef-3cac-477b-8fcd-bea1a564241c} REG_DWORD 0x1

Not

Azure Market'teki Windows Server 2012 R2 görüntüleri, Aralık 2015'ten itibaren varsayılan olarak hotfix KB3114025 yüklü bir şekilde sunulmaktadır.

İş yükünüz kısıtlanıyor

Bir dosya paylaşımı için saniye başına G/Ç işlemleri (IOPS), giriş veya çıkış sınırlarına ulaşıldığında istekler kısıtlanır. Örneğin, istemci temel IOPS'yi aşarsa Azure Dosyalar hizmeti tarafından kısıtlanır. Sınırlama, istemcinin düşük performansla karşılaşmasına neden olabilir.

Standart ve premium dosya paylaşımlarının sınırlarını anlamak için bkz. Dosya paylaşımı ve dosya ölçeklendirme hedefleri. İş yükünüze bağlı olarak, kısıtlama genellikle standart Azure dosya paylaşımlarından premium paylaşımlarına geçiş yaparak önlenebilir.

Paylaşım düzeyinde veya depolama hesabı düzeyinde kısıtlamanın yüksek gecikme, düşük aktarım hızı ve genel performans sorunlarına nasıl neden olabileceği hakkında daha fazla bilgi edinmek için bkz. Paylaşım veya depolama hesabı kısıtlanıyor.

Yüksek gecikme süresi, düşük aktarım hızı veya düşük IOPS

Neden 1: Paylaşım veya depolama hesabı kısıtlanıyor

Paylaşım veya depolama hesabınızın kısıtlanıp kısıtlanmadığını onaylamak için portaldan Azure ölçümlerine erişebilir ve bunları kullanabilirsiniz. Ayrıca, bir paylaşımın kısıtlanması veya kısıtlanmak üzere olması durumunda sizi bilgilendirecek uyarılar da oluşturabilirsiniz. Bakınız: Azure Dosya sorunlarını uyarılar oluşturarak giderme.

Önemli

Standart depolama hesaplarında hız sınırlaması veya kısıtlama, depolama hesabı düzeyinde gerçekleşir. Premium dosya paylaşımları için kısıtlama, paylaşım düzeyinde gerçekleşir.

  1. Azure portalda depolama hesabınıza gidin.

  2. Sol bölmedeki İzleme'nin altında Ölçümler'i seçin.

  3. Depolama hesabı kapsamınız için ölçüm ad alanı olarak Dosya'yı seçin.

  4. Ölçüm olarak İşlemler'i seçin.

  5. Yanıt türü için bir filtre ekleyin ve ardından herhangi bir isteğin kısıtlanıp kısıtlanmadığını denetleyin.

    Standart dosya paylaşımları için, bir istek istemci hesabı düzeyinde sınırlandırıldığında aşağıdaki yanıt türleri günlüğe kaydedilir:

    • MüşteriHesapTalebiSınırlamaHatası
    • MüşteriHesabıBantGenişliğiKısıtlamaHatası

    Premium dosya paylaşımları için, bir istek paylaşım düzeyinde sınırlandırıldığında aşağıdaki yanıt türleri günlüğe kaydedilir.

    • Paylaşım Çıkışı Kısıtlaması ile Başarı
    • Paylaşım Giriş Yavaşlatma ile Başarı
    • Paylaşılan IOPS Kısıtlamasında Başarı
    • İstemciPaylaşımÇıkışKısıtlamaHatası
    • İstemciPaylaşımGirişAzaltmaHatası
    • ClientShareIopsThrottlingError

    Kısıtlanmış bir isteğin kimliği Kerberos ile doğrulandıysa, kimlik doğrulama protokolünü gösteren bir ön ek görebilirsiniz, örneğin:

    • KerberosBaşarıPaylaşımÇıkışDışınaKısıtlama
    • KerberosBaşarıPaylaşımGirişKısıtlaması

    Her yanıt türü hakkında daha fazla bilgi edinmek için bkz. Ölçüm boyutları.

    'Yanıt türü' özellik filtresini gösteren ekran görüntüsü.

Çözüm

Premium dosya paylaşımı kullanıyorsanız, IOPS sınırını artırmak için sağlanan dosya paylaşımı boyutunu artırın. Daha fazla bilgi edinmek için Premium dosya paylaşımları için sağlamayı anlama konusuna bakın.

Neden 2: Meta veri veya ad alanı ağırlıklı iş yükü

İsteklerinizin çoğu meta veri odaklıysa (createfile, openfile, closefile, queryinfo veya querydirectory gibi), gecikme süresi okuma/yazma işlemlerinden daha kötü olacaktır.

İsteklerinizin çoğunun meta veri odaklı olup olmadığını belirlemek için, neden 1'de daha önce açıklandığı gibi 1-4 arası adımları izleyerek başlayın. 5. adım için, Yanıt türü için filtre eklemek yerine API adı için bir özellik filtresi ekleyin. Daha fazla bilgi için bkz. Meta veri IOPS'lerine göre kullanımı izleme.

'API adı' özellik filtresini gösteren ekran görüntüsü.

Geçici Çözümler

  • Uygulamanın meta veri işlemlerinin sayısını azaltmak için değiştirilip değiştirilemeyeceğini denetleyin.

  • Premium SMB Azure dosya paylaşımları kullanıyorsanız meta verileri önbelleğe alma özelliğini kullanın.

  • Dosya paylaşımını aynı depolama hesabı içindeki birden çok dosya paylaşımına ayırın.

  • Dosya paylaşımına bir sanal sabit disk (VHD) ekleyin ve verilere karşı dosya işlemleri gerçekleştirmek için istemciden VHD'yi bağlayın. Bu yaklaşım, tek yazarlı/okuyuculu senaryolar veya birden fazla okuyuculu ve yazarın olmadığı senaryolar için uygundur. Dosya sistemi Azure Dosyalar yerine istemciye ait olduğundan, meta veri işlemlerinin yerel olmasını sağlar. Kurulum, yerel olarak doğrudan bağlı depolamaya benzer bir performans sunar. Bununla birlikte, veriler bir VHD'de olduğundan, REST API gibi SMB bağlaması dışında başka herhangi bir yolla veya Azure portalı üzerinden erişilemez.

    1. Azure dosya paylaşımına erişmesi gereken makineden depolama hesabı anahtarını kullanarak dosya paylaşımını bağlayın ve kullanılabilir bir ağ sürücüsüne (ör. Z:) eşleyin.
    2. Disk Yönetimi'negidin ve Eylem > VHD Oluştur'u seçin.
    3. Konum'u, Azure dosya paylaşımının eşleştirildiği ağ sürücüsüne ayarlaryın, Sanal sabit sürücü boyutunu gereken şekilde ayarlayın ve Sabit boyut'u seçin.
    4. Tamam'ı seçin. VHD oluşturma işlemi tamamlandıktan sonra otomatik olarak bağlanacak ve ayrılmamış yeni bir disk görünecektir.
    5. Yeni bilinmeyen diske sağ tıklayın ve Diski Başlat'ı seçin.
    6. Ayrılmamış alana sağ tıklayın ve Yeni Basit Birim oluşturun.
    7. Disk Yönetimi'nde okuma/yazma erişimine sahip bu VHD'yi temsil eden yeni bir sürücü harfi (ör. E:) görmeniz gerekir. Dosya Gezgini'nde, eşlenen Azure dosya paylaşımının ağ sürücüsünde (bu örnekte Z:) yeni VHD'yi görmeniz gerekir. Net olmak gerekirse iki sürücü harfi bulunmalıdır: Z: üzerindeki standart Azure dosya paylaşımı ağ eşlemesi ve E: sürücüsündeki VHD eşlemesi.
    8. Azure dosya paylaşımı eşlenen sürücüsüne (Z:) kıyasla VHD eşlenen sürücüsündeki (E:) dosyalara yönelik ağır meta veri işlemlerinde çok daha iyi bir performans olmalıdır. İstenirse eşlenen ağ sürücüsünün (Z:) bağlantısını kesmek ve bağlı VHD sürücüsüne (E:) erişmeye devam etmek mümkün olacaktır.

Neden 3: Tek iş parçacıklı uygulama

Kullandığınız uygulama tek iş parçacıklıysa bu kurulum, sağlanan paylaşım boyutunuza bağlı olarak mümkün olan en yüksek aktarım hızına göre önemli ölçüde daha düşük IOPS aktarım hızına neden olabilir.

Çözüm

  • İş parçacığı sayısını artırarak uygulama paralelliğini artırın.
  • Paralelliğin mümkün olduğu uygulamalara geçin. Örneğin, kopyalama işlemleri için Windows istemcilerinden AzCopy veya RoboCopy ya da Linux istemcilerinden gelen paralel komutu kullanabilirsiniz.

Neden 4: SMB kanalı sayısı dört'ü aşıyor

Çok Kanallı SMB kullanıyorsanız ve sahip olduğunuz kanal sayısı dört'ü aşıyorsa, bu düşük performansa neden olur. Bağlantı sayınızın dört'ü aşıp aşmadığını belirlemek için PowerShell cmdlet'ini get-SmbClientConfiguration kullanarak geçerli bağlantı sayısı ayarlarını görüntüleyin.

Çözüm

Toplam kanalların dört'ü aşmaması için SMB için NIC başına Windows ayarını ayarlayın. Örneğin, iki NIC'niz varsa, aşağıdaki PowerShell cmdlet'ini kullanarak NIC başına maksimum değeri iki olarak ayarlayabilirsiniz: Set-SmbClientConfiguration -ConnectionCountPerRssNetworkInterface 2.

Neden 5: Ön okuma boyutu çok küçük (yalnızca NFS)

Linux çekirdek sürümü 5.4'den başlayarak, Linux NFS istemcisi varsayılan read_ahead_kb 128 kibibayt (KiB) değerini kullanır. Bu küçük değer, büyük dosyalar için okuma aktarım hızı miktarını azaltabilir.

Çözüm

Çekirdek parametre değerini 15 mebibayta (MiB) artırmanızı read_ahead_kb öneririz. Bu değeri değiştirmek için Linux çekirdek cihaz yöneticisi udev'de bir kural ekleyerek okuma boyutunu kalıcı olarak ayarlayın. Şu adımları izleyin:

  1. Bir metin düzenleyicisinde, aşağıdaki metni girip kaydederek /etc/udev/rules.d/99-nfs.rules dosyasını oluşturun:

    SUBSYSTEM=="bdi" \
, ACTION=="add" \
, PROGRAM="/usr/bin/awk -v bdi=$kernel 'BEGIN{ret=1} {if ($4 == bdi) {ret=0}} END{exit ret}' /proc/fs/nfsfs/volumes" \
, ATTR{read_ahead_kb}="15360"

  2. Konsolda udevadm komutunu süper kullanıcı olarak çalıştırıp kural dosyalarını ve diğer veritabanlarını yeniden yükleyerek udev kuralını uygulayın. Udev'nin yeni dosyadan haberdar olmasını sağlamak için bu komutu yalnızca bir kez çalıştırmanız yeterlidir.

    sudo udevadm control --reload

İstekler için çok yüksek gecikme süresi

Neden

İstemci VM dosya paylaşımından farklı bir bölgede bulunabilir. Yüksek gecikme süresinin diğer bir nedeni de istemcinin veya ağın neden olduğu gecikme süresi olabilir.

Çözüm

  • Uygulamayı, dosya paylaşımıyla aynı bölgede bulunan bir VM'den çalıştırın.
  • Depolama hesabınız için Azure portalda Azure İzleyici aracılığıyla SuccessE2ELatency ve SuccessServerLatency işlem ölçümlerini gözden geçirin. SuccessE2ELatency ile SuccessServerLatency ölçüm değerleri arasındaki yüksek fark, muhtemelen ağ veya istemciden kaynaklanan gecikme süresinin göstergesidir. Azure Dosyalar İzleme verileri başvurusunda İşlem ölçümlerine bakın.

İstemci ağ tarafından desteklenen en yüksek aktarım hızına ulaşamıyor

Neden

Olası nedenlerden biri, standart dosya paylaşımları için çok kanallı SMB desteği olmamasıdır. şu anda Azure Dosyalar standart dosya paylaşımları için yalnızca tek kanalı desteklediğinden istemci VM'den sunucuya tek bir bağlantı vardır. Bu tek bağlantı istemci VM'sinde tek bir çekirdeğe sabitlendiğinden, vm'den ulaşılabilen en yüksek aktarım hızı tek bir çekirdekle bağlıdır.

Geçici çözüm

  • Premium dosya paylaşımları için Çok Kanallı SMB'yi etkinleştirin.
  • Daha büyük bir çekirdekle vm almak, aktarım hızını artırmaya yardımcı olabilir.
  • İstemci uygulamasının birden çok VM'den çalıştırılması aktarım hızını artırır.
  • Mümkün olduğunda REST API'lerini kullanın.
  • NFS Azure dosya paylaşımları için nconnect kullanılabilir. Bkz . NFS Azure dosya paylaşımı performansını nconnect ile geliştirme.

Linux sanal makinesine bağlanmış Azure dosya paylaşımında yavaş performans

Neden 1: Önbelleğe alma

Yavaş performansın olası nedenlerinden biri devre dışı bırakılmış önbelleğe alma işlemidir. Önbelleğe alma, bir dosyaya tekrar tekrar erişiyorsanız yararlı olabilir. Aksi takdirde, bu bir ek yük olabilir. Önbelleği devre dışı bırakmadan önce kullanıp kullanmadığınızı denetleyin.

Neden 1 için çözüm

Önbelleğe almanın devre dışı bırakılıp bırakılmadığını denetlemek için cache= girdisini arayın.

Cache=none, önbelleğe almanın devre dışı bırakıldığını gösterir. Varsayılan önbelleğe alma veya "katı" önbelleğe alma modunun etkinleştirildiğinden emin olmak için varsayılan bağlama komutunu kullanarak veya bağlama komutuna cache=strict seçeneğini açıkça ekleyerek paylaşımı yeniden bağlayın.

Bazı senaryolarda serverino bağlama seçeneği, ls komutunun her dizin girdisine karşı stat çalıştırmasına neden olabilir. Bu davranış, büyük bir dizini listelerken performans düşüşüyle sonuçlanır. /etc/fstab girdinizdeki bağlama seçeneklerini de kontrol edebilirsiniz:

//azureuser.file.core.windows.net/cifs /cifs cifs vers=2.1,serverino,username=xxx,password=xxx,dir_mode=0777,file_mode=0777

Ayrıca, sudo mount | grep cifs komutunu çalıştırıp çıktısını denetleyerek de doğru seçeneklerin kullanılıp kullanılmadığını kontrol edebilirsiniz. Aşağıda örnek bir çıktı verilmiştir:

//azureuser.file.core.windows.net/cifs on /cifs type cifs (rw,relatime,vers=2.1,sec=ntlmssp,cache=strict,username=xxx,domain=X,uid=0,noforceuid,gid=0,noforcegid,addr=192.168.10.1,file_mode=0777, dir_mode=0777,persistenthandles,nounix,serverino,mapposix,rsize=1048576,wsize=1048576,actimeo=1)

cache=strict veya serverino seçeneği yoksa belgelerden bağlama komutunu çalıştırarak Azure Dosyalar'ı çıkarın ve yeniden bağlayın. Ardından, /etc/fstab girdisinin doğru seçeneklere sahip olduğunu yeniden denetleyin.

Neden 2: Hız Kesme

İstekleriniz kısıtlanıyor olabilir ve bir kuyruğa gönderiliyor olabilir. Azure İzleyici'deki Azure Depolama ölçümlerinden yararlanarak bunu doğrulayabilirsiniz. Ayrıca, size bir paylaşımın kısıtlandığını veya kısıtlanmak üzere olduğunu bildiren uyarılar da oluşturabilirsiniz. Bakınız: Azure Dosya sorunlarını uyarılar oluşturarak giderme.

Neden 2 için çözüm

Uygulamanızın Azure Dosyalar ölçek hedefleri içinde olduğundan emin olun. Standart Azure dosya paylaşımlarını kullanıyorsanız premium dosya paylaşımlarına geçmeyi göz önünde bulundurun.

Neden 3: Azure Dosya Paylaşımı kapasiteye ulaşıyor

Azure dosya paylaşımı kapasitesine ulaşmak üzereyse, depolamayı iyileştirmek için en büyük dosya ve dizinleri tanımlamak önemli bir adımdır. Bu adım, hangi dosya ve klasörlerin en çok alan kullandığını anlamanıza yardımcı olur.

Geçici çözüm

Paylaşımın tamamında depolama kullanımına ilişkin kapsamlı bir görünüm elde etmek için paylaşımın kökünü bağlayın. Bu eylem, dosya ve dizin boyutlarının kapsamlı bir incelemesini sağlar. Dosya paylaşımının kökünde, en büyük dosyaları ve dizinleri tanımlamak için aşağıdaki komutları çalıştırın:

	cd /path/to/mount/point
	du -ah --max-depth=1 | sort -rh | head -n 20

Bu komut, en büyük 20 dosya ve dizini azalan düzende görüntüler. Bu ekran, depolama tüketimine net bir genel bakış sağlar.

Paylaşımın kökünü bağlayamazsanız, depolama kullanımını analiz etmek için Azure Depolama Gezgini'ni veya üçüncü taraf bir aracı kullanın. Bu araçlar, paylaşımı bağlamanıza gerek kalmadan dosya ve dizin boyutlarıyla ilgili benzer içgörüler sağlar.

Linux istemcilerinde aktarım hızı Windows istemcilerinden daha düşüktür

Neden

Bu, Linux'ta SMB istemcisinin uygulanmasını etkileyen bilinen bir sorundur.

Geçici çözüm

  • Yükü birden çok VM'ye yayın.
  • Aynı VM'de, seçeneği nosharesock olan birden çok bağlama noktası kullanın ve yükü bu bağlama noktalarına dağıtın.
  • Linux'ta her nostrictsync çağrıda SMB flush işlemini zorlamamak için bir fsync seçeneği kullanarak bağlamayı deneyin. Azure Dosyalar için bu seçenek veri tutarlılığını engellemez, ancak dizin listelerinde (ls -l komut) eski dosya meta verilerine neden olabilir. komutunu kullanarak stat dosya meta verilerini doğrudan sorgulamak en up-totarih dosya meta verilerini döndürür.

Kapsamlı açma/kapatma işlemleri içeren meta veri yoğunluklu iş yükleri için yüksek gecikme süreleri

Neden

Dizin kiralama desteğinin eksikliği.

Geçici çözüm

  • Mümkünse, kısa bir süre içinde aynı dizinde çok sık dosya açma/kapama işlemi yapmaktan kaçının.
  • Linux VM'leri için, actimeo=<sec> bir bağlama seçeneği olarak belirterek dizin girişi önbellek zaman aşımını artırın. Varsayılan olarak, zaman aşımı 1 saniyedir, bu nedenle 30 saniye gibi daha büyük bir değer yardımcı olabilir.
  • CentOS Linux veya Red Hat Enterprise Linux (RHEL) VM'leri için sistemi CentOS Linux 8.2 veya RHEL 8.2'ye yükseltin. Diğer Linux dağıtımları için çekirdeği 5.0 veya sonraki bir sürüme yükseltin.

Dosya ve klasörlerin yavaş numaralandırılması

İstemci makinesinde büyük dizinler için yeterli önbellek veya bellek yoksa bu sorun oluşabilir.

Bu sorunu çözmek için, istemci makinede daha büyük dizin listelerinin önbelleğe alınmasına izin vermek amacıyla DirectoryCacheEntrySizeMax kayıt defteri değerini ayarlayın:

  • Konum: HKEY_LOCAL_MACHINE\System\CCS\Services\Lanmanworkstation\Parameters
  • Değer adı: DirectoryCacheEntrySizeMax
  • Değer türü = DWORD

Örneğin, bunu 0x100000 olarak ayarlayabilir ve performansın iyileşip iyileşmediğini görebilirsiniz.

Azure dosya paylaşımlarına yavaş dosya kopyalama

Dosyaları Azure Dosyalar hizmetine aktarmaya çalıştığınızda performansın yavaş olduğunu görebilirsiniz. Belirli bir minimum G/Ç boyutu gereksiniminiz yoksa en iyi performans için G/Ç boyutu olarak 1 MiB kullanmanızı öneririz.

Windows'da Azure Dosyaları ile yavaş dosya alışverişi

  • Yazma işlemleriyle genişlettiğiniz dosyanın son boyutunu biliyorsanız ve dosyanın yazılmamış kısmı sıfır içeriyorsa ve bu durumda yazılımınızda uyumluluk sorunları olmuyorsa, her yazma işlemini genişleten bir yazma işlemi yapmak yerine dosya boyutunu önceden ayarlayın.

  • Doğru kopyalama yöntemini kullanın:

    • İki dosya paylaşımı arasındaki aktarımlar için AzCopy'yi kullanın.
    • Şirket içi bilgisayardaki dosya paylaşımları arasında Robocopy'yi kullanın.

Aşırı DirectoryOpen/DirectoryClose çağrıları

Neden

DirectoryOpen/DirectoryClose çağrılarının sayısı, başlıca API çağrıları arasında yer alıyorsa ve istemcinin bu kadar çok çağrı yapmasını beklemiyorsanız sorun Azure istemci VM'sinde yüklü virüsten koruma yazılımından kaynaklanıyor olabilir.

Geçici çözüm

Bu soruna yönelik bir düzeltmeyi Windows için Nisan Platform Güncelleştirmesi'nde bulabilirsiniz.

SMB Çoklu Kanal tetiklenmiyor

Neden

Yeniden bağlama olmadan Çok Kanallı SMB yapılandırma ayarlarında yapılan son değişiklikler.

Çözüm

  • Windows SMB istemcisi veya hesap SMB çok kanallı yapılandırma ayarlarında yapılan değişikliklerden sonra paylaşımı çıkarmanız, 60 saniye beklemeniz ve çok kanallıyı tetiklemeniz için paylaşımı yeniden bağlamanız gerekir.
  • Windows İstemci İşletim Sistemi için, QD=8 gibi yüksek kuyruğa derinlik veren I/O yükü oluşturun, örneğin SMB Çok Kanallı'yı tetikleyen bir dosya kopyalama. Sunucu işletim sistemi için Çok Kanallı SMB, QD=1 olduğunda tetiklenir, yani paylaşım üzerine herhangi bir G/Ç başlatır başlatmaz.

Dosyaların zip paketi açılırken yavaş performans

Tam sıkıştırma yöntemine ve kullanılan sıkıştırmayı açma işlemine bağlı olarak, sıkıştırmayı açma işlemleri yerel diskinize göre Azure dosya paylaşımında daha yavaş çalışabilir. Bunun nedeni genellikle sıkıştırma araçlarının sıkıştırılmış bir arşivin sıkıştırmasını kaldırma işleminde bir dizi meta veri işlemi gerçekleştirmesidir. En iyi performans için sıkıştırılmış arşivi Azure dosya paylaşımından yerel diskinize kopyalamanızı, sıkıştırmayı açmanızı ve ardından Robocopy (veya AzCopy) gibi bir kopyalama aracını kullanarak Azure dosya paylaşımına geri kopyalamanızı öneririz. Robocopy gibi bir kopyalama aracı kullanmak, Azure Dosyalar'daki meta veri işlemlerinin yerel diskinize göre düşen performansını, verileri paralel olarak kopyalayan birden çok iş parçacığı kullanarak telafi edebilir.

Dosya paylaşımlarında barındırılan web sitelerinde yüksek gecikme

Neden

Dosya paylaşımlarında yüksek sayıda dosya değişikliği bildirimi yüksek gecikme süresine neden olabilir. Bu durum genellikle derin iç içe geçmiş dizin yapısına sahip dosya paylaşımlarında barındırılan web sitelerinde oluşur. Tipik bir senaryo, varsayılan yapılandırmadaki her dizin için dosya değişikliği bildiriminin ayarlandığı IIS tarafından barındırılan web uygulamasıdır. İstemcinin kaydedildiği paylaşımdaki her değişiklik (ReadDirectoryChangesW), dosya hizmetinden istemciye bir değişiklik bildirimi göndererek sistem kaynaklarını alır ve sorun değişiklik sayısıyla kötüleşir. Bu, paylaşım hızının yavaşlamasına ve sonuç olarak istemci tarafı gecikme süresinin daha yüksek olmasına neden olabilir.

Onaylamak için portalda Azure Ölçümleri'ni kullanabilirsiniz.

  1. Azure portalda depolama hesabınıza gidin.
  2. Soldaki menüde İzleme'nin altında Ölçümler'i seçin.
  3. Depolama hesabı kapsamınız için ölçüm ad alanı olarak Dosya'yı seçin.
  4. Ölçüm olarak İşlemler'i seçin.
  5. ResponseType için bir filtre ekleyin ve herhangi bir isteğin SuccessWithThrottling yanıt kodu (SMB veya NFS için) veya ClientThrottlingError (REST için) olup olmadığını denetleyin.

Çözüm

  • Dosya değişikliği bildirimi kullanılmıyorsa, dosya değişikliği bildirimini devre dışı bırakın (tercih edilir).

    • FCNMode'yi güncelleştirerek dosya değişikliği bildirimini devre dışı bırakın.
    • Kayıt defterinizde HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\W3SVC\Parameters\ConfigPollMilliSeconds ayarlayarak IIS Çalışan İşlemi (W3WP) yoklama aralığını 0 olarak güncelleştirin ve W3WP işlemini yeniden başlatın. Bu ayar hakkında bilgi edinmek için bkz . IIS'nin birçok bölümü tarafından kullanılan ortak kayıt defteri anahtarları.

  • Yükü azaltmak için dosya değişikliği bildirim yoklama aralığının sıklığını artırın.

    W3WP çalışan işlemi yoklama aralığını gereksinimlerinize göre daha yüksek bir değere (örneğin, 10 veya 30 dakika) güncelleştirin. Kayıt defterinizdeki HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\W3SVC\Parameters\ConfigPollMilliSeconds ayarları yapın ve W3WP işlemini yeniden başlatın.

  • Web sitenizin eşlenmiş fiziksel dizini iç içe dizin yapısına sahipse, bildirim birimini azaltmak için dosya değişikliği bildirimlerinin kapsamını sınırlamayı deneyebilirsiniz. Varsayılan olarak IIS, sanal dizinin eşlendiği fiziksel dizindeki Web.config dosyalarındaki ve bu fiziksel dizindeki alt dizinlerin herhangi birindeki yapılandırmaları kullanır. Alt dizinlerde Web.config dosyalarını kullanmak istemiyorsanız, sanal dizindeki false öznitelik için allowSubDirConfig olarak belirtin. Daha fazla ayrıntı için buraya bakın.

    Eşlenen fiziksel alt dizinleri kapsamdan dışlamak için allowSubDirConfig içindeki IIS sanal dizin ayarını false olarak ayarlayın.

Ayrıca bkz.

Yardım için bize ulaşın

Sorularınız varsa Azure topluluk desteğine sorabilirsiniz. Ürün geri bildirimini Azure geri bildirim topluluğuna da gönderebilirsiniz.

  • Last updated on