Azure Dosyalar performans sorunlarını giderme

  • Makale

Not

Bu makalede başvuruda bulunan CentOS bir Linux dağıtımıdır ve Kullanım Ömrünün 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 öncelikle Performansı anlama Azure Dosyalar okumanızı öneririz.

Uygulandığı öğe

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 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 yüksek 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şlayarak varsayılan olarak düzeltme KB3114025 yüklüdür.

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

Bir dosya paylaşımı için saniyedeki G/Ç işlemlerine (IOPS), girişe veya çıkış sınırlarına ulaşıldığında istekler kısıtlanıyor. Örneğin, istemci temel IOPS'yi aşarsa, Azure Dosyalar hizmeti tarafından kısıtlanır. Azaltma, istemcinin düşük performans yaşaması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, standarttan premium Azure dosya paylaşımlarına geçiş yaparak azaltmanın önüne geçilebilir.

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 portalda 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

Büyük dosya paylaşımları (LFS) etkinleştirilmiş standart depolama hesapları için, azaltma hesap düzeyinde gerçekleşir. LFS etkinleştirilmeden premium dosya paylaşımları ve standart dosya paylaşımları için azaltma, paylaşım düzeyinde gerçekleşir.

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

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

  3. Depolama hesabınızın kapsamı 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 isteklerin kısıtlanıp kısıtlanmamış olup olmadığını denetleyin.

    Büyük dosya paylaşımları etkinleştirilmemiş standart 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:

    • SuccessWithThrottling
    • SuccessWithShareIopsThrottling
    • ClientShareIopsThrottlingError

    Büyük dosya paylaşımlarının etkinleştirildiği 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 protokollerini 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

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

İsteklerinizin çoğu meta veri odaklıysa (, , , closefileveya queryinfoquerydirectorygibicreatefileopenfile), 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ü filtresi eklemek yerine API adı için bir özellik filtresi ekleyin.

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

Geçi -ci çözüm

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

  • 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 yazıcı/okuyucu senaryolarında veya birden çok okuyucusu olan ve yazar içermeyen senaryolarda çalışır. Dosya sistemi Azure Dosyalar yerine istemciye ait olduğundan, meta veri işlemlerinin yerel olmasını sağlar. Kurulum, yerel 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üyle (ö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şimi olan bu VHD'yi temsil eden yeni bir sürücü harfi görmeniz gerekir (örneğin, E:). 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: üzerinde standart Azure dosya paylaşımı ağ eşlemesi ve E: sürücüsünde 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. İsterseniz, 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.
    • Bir Windows istemcisine VHD bağlamak için PowerShell cmdlet'ini Mount-DiskImage de kullanabilirsiniz.
    • Linux'ta VHD bağlamak için Linux dağıtımınızın belgelerine bakın. İşte bir örnek.

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 kanallarının 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 taneyi 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: 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 parametresi 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. 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. Bir 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 gerekir.

    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 portal'de 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 istemcinin neden olduğu gecikme süresinin göstergesidir. bkz. Azure Dosyalar İzleme verileri başvurusunda işlem ölçümleri.

İstemci ağ tarafından desteklenen maksimum 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 bir kanalı desteklediğinden istemci VM'den sunucuya yalnızca bir bağlantı vardır. Bu tek bağlantı istemci VM'sinde tek bir çekirdekle sabitlendiğinden, bir VM'den ulaşılabilen maksimum aktarım hızı tek bir çekirdekle bağlanır.

Geçici Çözüm

Linux VM'sinde bağlı bir Azure dosya paylaşımında yavaş performans

Neden 1: Önbelleğe Alma

Yavaş performansın olası nedenlerinden biri önbelleğe alma özelliğinin devre dışı bırakılması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 girişe cache= bakı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 çıkışı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şıyor ve istekleriniz 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 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ı kullanıyorsanız Premium'a geçmeyi göz önünde bulundurun.

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

Neden

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

Geçici Çözüm

  • Yükü birden çok VM'ye dağıtın.
  • 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 boşaltmasını 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 verileriyle sonuçlanabilir. 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, kayıt defteri değerini istemci makinesinde DirectoryCacheEntrySizeMax daha büyük dizin listelerinin önbelleğe alınmasını sağlayacak şekilde ayarlayın:

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

Örneğin, bunu olarak 0x100000 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 yavaş dosya kopyalama

  • 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ında herhangi bir aktarım 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, sorunun nedeni Azure istemci VM'sinde yüklü olan virüsten koruma yazılımı olabilir.

Geçici Çözüm

Bu soruna yönelik bir düzeltme Windows için Nisan Platform Güncelleştirmesi'nde sağlanır.

Ç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 dosyayı kopyalama. Sunucu işletim sistemi için SMB Çok Kanallı, QD=1 ile tetiklendiğinden, paylaşıma herhangi bir GÇ'yi başlatır başlatmaz.

Dosyaların sıkıştırmasını açtığınızda yavaş performans

Kullanılan sıkıştırma yöntemine ve 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ırmayı açma 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ı elde etmek için sıkıştırılmış arşivi Azure dosya paylaşımından yerel diskinize kopyalamanızı, sıkıştırmayı burada 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 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 daha da kötüleşir. Bu, paylaşım azaltmaya neden olabilir ve bu nedenle istemci tarafı gecikme süresinin daha yüksek olduğunu gösterir.

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

  1. Azure portal depolama hesabınıza gidin.
  2. Soldaki menüde İzleme'nin altında Ölçümler'i seçin.
  3. Depolama hesabınızın kapsamı 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ştirme bildirimi kullanılmıyorsa, dosya değiştirme bildirimini (tercih edilen) devre dışı bırakın.

  • 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ı gereksiniminize 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ının yanı sıra bu fiziksel dizindeki tüm alt dizinlerdeki yapılandırmayı kullanır. Alt dizinlerde Web.config dosyaları kullanmak istemiyorsanız, sanal dizindeki allowSubDirConfig özniteliğini belirtinfalse. Daha fazla ayrıntıya buradan ulaşabilirsiniz.

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

Ayrıca bkz.

Yardım için bize ulaşın

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