Aracılığıyla paylaş

Azure Dosyalar performans sorunlarını giderme

  • Makale

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ü SMB 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

İlk olarak, performans sorunları yaşamanıza neden olabilecek bazı yaygın nedenleri ekleyebilirsiniz.

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, oluşturma ve kapatma tanıtıcı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 çıkış görüntülenir:

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

Not

Azure Market'daki Windows Server 2012 R2 görüntüleri, Aralık 2015'te başlayan düzeltme KB3114025 varsayılan olarak yüklüdür.

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

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

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, standarttan premium Azure dosya paylaşımlarına geçiş yaparak azaltma genellikle önlenebilir.

Paylaşım düzeyinde veya depolama hesabı düzeyinde azaltmanın yüksek gecikme süresine, düşük aktarım hızına 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. Bkz. Uyarı oluşturarak Azure Dosyalar sorunlarını giderme.

Önemli

Standart depolama hesapları için azaltma, depolama hesabı düzeyinde gerçekleşir. Premium dosya paylaşımları için azaltma, paylaşım düzeyinde gerçekleşir.

  1. Azure portalında 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ıtlanmamış olup olmadığını denetleyin.

    Standart dosya paylaşımları için, bir istek istemci hesabı düzeyinde kısıtlanırsa aşağıdaki yanıt türleri günlüğe kaydedilir:

    • ClientAccountRequestThrottlingError
    • ClientAccountBandwidthThrottlingError

    Premium dosya paylaşımları için, bir istek paylaşım düzeyinde kısıtlanırsa aşağıdaki yanıt türleri günlüğe kaydedilir:

    • SuccessWithShareEgressThrottling
    • SuccessWithShareIngressThrottling
    • SuccessWithShareIopsThrottling
    • ClientShareEgressThrottlingError
    • ClientShareIngressThrottlingError
    • ClientShareIopsThrottlingError

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

    • KerberosSuccessWithShareEgressThrottling
    • KerberosSuccessWithShareIngressThrottling

    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 bkz . Premium dosya paylaşımları için sağlamayı anlama.

Neden 2: Meta veriler veya ad alanı ağır iş yükü

İsteklerinizin çoğu meta veri odaklıysa (, , , closefilequeryinfoveya querydirectorygibicreatefileopenfile), 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.

'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, birden çok okuyucusu olan ve yazar içermeyen tek yazar/okuyucu senaryoları için geçerlidir. 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. Ancak, veriler bir VHD'de olduğundan, REST API gibi SMB bağlaması dışında başka herhangi bir yolla veya Azure portalı üzerinden erişilemiyor.

    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 (örneğin, Z:) eşleyin.
    2. Disk Yönetimi'ne gidin ve Eylem > VHD Oluştur'u seçin.
    3. Konum'ı Azure dosya paylaşımının eşlendiği ağ sürücüsüne ayarlayın, sanal sabit disk boyutunu gerektiği gibi ayarlayın ve Sabit boyut'a tıklayın.
    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 (örneğin, E:) görmeniz gerekir. Dosya Gezgini'de, eşlenen Azure dosya paylaşımının ağ sürücüsünde (bu örnekte Z: ) yeni VHD'yi görmeniz gerekir. Açık 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. VHD eşlenen sürücüdeki (E:) dosyalara karşı ağır meta veri işlemlerinde Azure dosya paylaşımı eşlenmiş sürücüsüne (Z:) göre ç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 olmalıdı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: Önceden 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, ağ veya istemciden kaynaklanan gecikme süresinin göstergesidir. bkz. Azure Dosyalar İzleme verileri başvurusunda işlem ölçümleri.

İ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ı nconnect için 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 önbelleğe almayı devre dışı bırakmış olmasıdır. Ö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 girdiyi cache= arayın.

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

Bazı senaryolarda bağlama seçeneği komutun serverino her dizin girdisinde ls çalışmasına stat neden olabilir. Bu davranış, büyük bir dizini listelerken performans düşüşüyle sonuçılı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

Komutunu çalıştırıp çıktısını denetleyerek doğru seçeneklerin sudo mount | grep cifs kullanılıp kullanılmadığını da de kontrol edebilirsiniz. Aşağıda örnek bir çıkış 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 yeniden çıkarın ve bağlayın. Ardından , /etc/fstab girişinin doğru seçeneklere sahip olduğunu yeniden denetleyin.

Neden 2: Azaltma

Azaltmayla karşılaşmış ve istekleriniz bir kuyruğa gönderiliyor olabilir. Azure İzleyici'de Azure Depolama ölçümlerinden yararlanarak bunu doğrulayabilirsiniz. Ayrıca, bir paylaşımın kısıtlandığını veya kısıtlanmak üzere olduğunu size bildiren uyarılar da oluşturabilirsiniz. Bkz. Uyarı oluşturarak Azure Dosyalar sorunlarını 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.

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

Neden

Bu, Linux'ta SMB istemcisinin uygulanmasıyla ilgili bilinen bir sorundur.

Geçici çözüm

  • Yükü birden çok VM'ye yayma.
  • Aynı VM'de, bir nosharesock seçenekle birden çok bağlama noktası kullanın ve yükü bu bağlama noktalarına dağıtın.
  • Linux'ta, her fsync çağrıda SMB temizlemeyi zorlamamak için bir nostrictsync seçenekle 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 güncel 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 kiralamaları için destek eksikliği.

Geçici çözüm

  • Mümkünse, kısa bir süre içinde aynı dizinde aşırı açma/kapatma tutamacı kullanmaktan kaçının.
  • Linux VM'leri için bağlama seçeneği olarak belirterek actimeo=<sec> 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ş sabit listesi

Neden

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

Çözüm

Bu sorunu çözmek için, istemci makinesinde DirectoryCacheEntrySizeMax daha büyük dizin listelerinin önbelleğe alınmasını sağlamak için kayıt defteri değerini ayarlayın:

  • Yer: 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 dosyadaki yazılmamış kuyruk sıfır içerdiğinde yazılımınızda uyumluluk sorunları yoksa, 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 kullanın.
    • Şirket içi bilgisayardaki dosya paylaşımları arasında Robocopy kullanın.

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

Neden

DirectoryOpen/DirectoryClose çağrılarının sayısı en önemli 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üzeltme Windows için Nisan Platform Güncelleştirmesi'nde kullanılabilir.

Çok Kanallı SMB 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 istemci işletim sistemi için QD=8 gibi yüksek kuyruk derinliğine sahip GÇ 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 ile tetiklendiğinden, paylaşımda herhangi bir GÇ'yi başlatır başlatmaz.

Dosyaların sıkıştırmasını açarken 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ırma işlemleri azure dosya paylaşımında yerel diskinize göre 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, verileri paralel olarak kopyalamak için birden çok iş parçacığı kullanarak yerel diskinize göre Azure Dosyalar meta veri işlemlerinin düşük performansını telafi edebilir.

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

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 azaltmaya neden olabilir ve bu nedenle istemci tarafı gecikme süresi daha yüksek olabilir.

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

  1. Azure portalında 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 ayarlayıp HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\W3SVC\Parameters\ConfigPollMilliSeconds W3WP işlemini yeniden başlatarak IIS Çalışan İşlemi (W3WP) yoklama aralığını 0 olarak güncelleştirin. 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ı.

  • Birimi azaltmak için dosya değişikliği bildirimi 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 defterinizde ayarlayın HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\W3SVC\Parameters\ConfigPollMilliSeconds 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 yapılandırmayı ve bu fiziksel dizindeki alt dizinleri kullanır. Alt dizinlerde Web.config dosyalarını kullanmak istemiyorsanız, sanal dizindeki allowSubDirConfig öznitelik için belirtinfalse. Daha fazla ayrıntı için buraya bakın.

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

Ayrıca bkz.

Yardım için bizimle iletişim kurun

Sorularınız varsa veya yardıma ihtiyacınız varsa bir destek isteği oluşturun veya Azure topluluk desteğine sorun. Ürün geri bildirimini Azure geri bildirim topluluğuna da gönderebilirsiniz.