Felsöka prestandaproblem i Azure Files

Den här artikeln innehåller vanliga problem som rör Prestanda för Azure-filresurser och potentiella orsaker och lösningar. För att få ut mesta möjliga av den här felsökningsguiden rekommenderar vi att du först läser Förstå Azure Files-prestanda.

Gäller för

Typ av filresurs	SMB	NFS
Standardfilresurser (GPv2), LRS/ZRS
Standardfilresurser (GPv2), GRS/GZRS
Premiumfilresurser (FileStorage), LRS/ZRS

Allmän prestandafelsökning

Först utesluter du några vanliga orsaker till att du kanske har prestandaproblem.

Du kör ett gammalt operativsystem

Om den virtuella klientdatorn (VM) kör Windows 8.1 eller Windows Server 2012 R2, eller en äldre Linux-distribution eller kernel, kan det uppstå prestandaproblem vid åtkomst till Azure-filresurser. Uppgradera antingen klientoperativsystemet eller tillämpa korrigeringarna nedan.

Din arbetsbelastning begränsas

Begäranden begränsas när I/O-åtgärderna per sekund (IOPS), ingress- eller utgående gränser för en filresurs nås. Om klienten till exempel överskrider baslinje-IOPS begränsas den av Azure Files-tjänsten. Begränsning kan leda till att klienten får dåliga prestanda.

Information om gränserna för standard- och premiumfilresurser finns i Mål för filresurs- och filskalning. Beroende på din arbetsbelastning kan du ofta undvika begränsningar genom att flytta från Standard till Premium Azure-filresurser.

Mer information om hur begränsning på resursnivå eller lagringskontonivå kan orsaka problem med långa svarstider, lågt dataflöde och allmänna prestanda finns i Dela eller lagringskontot begränsas.

Hög svarstid, lågt dataflöde eller låg IOPS

Orsak 1: Resurs- eller lagringskontot begränsas

För att bekräfta om ditt resurs- eller lagringskonto begränsas kan du komma åt och använda Azure-mått i portalen. Du kan också skapa aviseringar som meddelar dig om en resurs begränsas eller håller på att begränsas. Se Felsöka Azure Files genom att skapa aviseringar.

1. Gå till ditt lagringskonto i Azure-portalen.

2. I den vänstra rutan under Övervakning väljer du Mått.

3. Välj Arkiv som måttnamnområde för lagringskontots omfång.

4. Välj Transaktioner som mått.

5. Lägg till ett filter för svarstyp och kontrollera sedan om några begäranden har begränsats.

   För standardfilresurser loggas följande svarstyper om en begäran begränsas på klientkontonivå:

   • ClientAccountRequestThrottlingError
   • ClientAccountBandwidthThrottlingError

   För Premium-filresurser loggas följande svarstyper om en begäran begränsas på resursnivå:

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

   Om en begränsad begäran autentiserades med Kerberos kan du se ett prefix som anger autentiseringsprotokollet, till exempel:

   • KerberosSuccessWithShareEgressThrottling
   • KerberosSuccessWithShareIngressThrottling

   Mer information om varje svarstyp finns i Måttdimensioner.

   

Lösning

Om du använder en Premium-filresurs ökar du storleken på den etablerade filresursen för att öka IOPS-gränsen. Mer information finns i Förstå etablering för Premium-filresurser.

Orsak 2: Hög arbetsbelastning för metadata eller namnområde

Om de flesta av dina begäranden är metadatacentrerade (till exempel createfile, openfile, closefile, queryinfoeller querydirectory), blir svarstiden sämre än för läs-/skrivåtgärder.

För att avgöra om de flesta av dina begäranden är metadatacentrerade börjar du med att följa steg 1–4 som tidigare beskrivits i Orsak 1. För steg 5 lägger du till ett egenskapsfilter för API-namn i stället för att lägga till ett filter för svarstyp.

Provisoriska lösningar

• Kontrollera om programmet kan ändras för att minska antalet metadataåtgärder.

• Om du använder Premium SMB Azure-filresurser använder du cachelagring av metadata.

• Avgränsa filresursen i flera filresurser inom samma lagringskonto.

• Lägg till en virtuell hårddisk (VHD) på filresursen och montera den virtuella hårddisken från klienten för att utföra filåtgärder mot data. Den här metoden fungerar för scenarier eller scenarier med enstaka skrivare/läsare med flera läsare och inga skribenter. Eftersom filsystemet ägs av klienten i stället för Azure Files kan metadataåtgärder vara lokala. Konfigurationen ger prestanda som liknar den för lokalt direktansluten lagring. Men eftersom data finns i en virtuell hårddisk kan de inte nås via något annat sätt än SMB-monteringen, till exempel REST API eller via Azure-portalen.

  1. Från datorn som behöver komma åt Azure-filresursen monterar du filresursen med hjälp av lagringskontonyckeln och mappar den till en tillgänglig nätverksenhet (till exempel Z:).
  2. Gå till Diskhantering och välj Åtgärd > Skapa virtuell hårddisk.
  3. Ange Plats till den nätverksenhet som Azure-filresursen mappas till, ange Storlek på virtuell hårddisk efter behov och välj Fast storlek.
  4. Välj OK. När den virtuella hårddisken har skapats monteras den automatiskt och en ny oallokerad disk visas.
  5. Högerklicka på den nya okända disken och välj Initiera disk.
  6. Högerklicka på det oallokerade området och skapa en ny enkel volym.
  7. Du bör se en ny enhetsbeteckning i Diskhantering som representerar den här virtuella hårddisken med läs-/skrivåtkomst (till exempel E:). I Istraživač datoteka bör du se den nya virtuella hårddisken på den mappade Azure-filresursens nätverksenhet (Z: i det här exemplet). För att vara tydlig bör det finnas två enhetsbeteckningar: standardmappningen av Azure-filresursnätverk på Z:, och VHD-mappningen på E: -enheten.
  8. Det bör finnas mycket bättre prestanda vid tunga metadataåtgärder mot filer på den VHD-mappade enheten (E:) jämfört med den mappade Azure-filresursenheten (Z:). Om du vill bör det vara möjligt att koppla från den mappade nätverksenheten (Z:) och fortfarande komma åt den monterade VHD-enheten (E:).
  • Om du vill montera en virtuell hårddisk på en Windows-klient kan du också använda PowerShell-cmdleten Mount-DiskImage .
  • Om du vill montera en virtuell hårddisk på Linux läser du dokumentationen för din Linux-distribution. Här är ett exempel.

Orsak 3: Entrådat program

Om programmet som du använder är enkeltrådat kan den här konfigurationen resultera i betydligt lägre IOPS-dataflöde än det maximala möjliga dataflödet, beroende på din etablerade resursstorlek.

Lösning

• Öka programparallelliteten genom att öka antalet trådar.
• Växla till program där parallellitet är möjligt. För kopieringsåtgärder kan du till exempel använda AzCopy eller RoboCopy från Windows-klienter eller det parallella kommandot från Linux-klienter.

Orsak 4: Antalet SMB-kanaler överskrider fyra

Om du använder SMB MultiChannel och antalet kanaler som du har överskrider fyra resulterar detta i dåliga prestanda. Om du vill ta reda på om antalet anslutningar överskrider fyra använder du PowerShell-cmdleten get-SmbClientConfiguration för att visa de aktuella inställningarna för antal anslutningar.

Lösning

Ange inställningen Windows per nätverkskort för SMB så att de totala kanalerna inte överskrider fyra. Om du till exempel har två nätverkskort kan du ange maximalt antal nätverkskort till två med hjälp av följande PowerShell-cmdlet: Set-SmbClientConfiguration -ConnectionCountPerRssNetworkInterface 2.

Orsak 5: Skrivskyddad storlek är för liten (endast NFS)

Från och med Linux-kernelversion 5.4 använder Linux NFS-klienten ett standardvärde read_ahead_kb på 128 kibibyte (KiB). Det här lilla värdet kan minska mängden läsdataflöde för stora filer.

Lösning

Vi rekommenderar att du ökar read_ahead_kb kernelparametervärdet till 15 mebibyte (MiB). Om du vill ändra det här värdet anger du skrivskyddad storlek beständigt genom att lägga till en regel i udev, en Linux-kernelenhetshanterare. Följ de här stegen:

1. I en textredigerare skapar du filen /etc/udev/rules.d/99-nfs.rules genom att ange och spara följande text:

   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. I en konsol tillämpar du udev-regeln genom att köra kommandot udevadm som en superanvändare och läsa in regelfilerna och andra databaser igen. För att göra udev medveten om den nya filen behöver du bara köra det här kommandot en gång.

   sudo udevadm control --reload
   

Mycket långa svarstider för begäranden

Orsak

Den virtuella klientdatorn kan finnas i en annan region än filresursen. Andra orsaker till långa svarstider kan bero på den svarstid som orsakas av klienten eller nätverket.

Lösning

• Kör programmet från en virtuell dator som finns i samma region som filresursen.
• För ditt lagringskonto granskar du transaktionsmåtten SuccessE2ELatency och SuccessServerLatency via Azure Monitor i Azure-portalen. En stor skillnad mellan måttvärdena SuccessE2ELatency och SuccessServerLatency är en indikation på svarstid som sannolikt orsakas av nätverket eller klienten. Se Transaktionsmått i Datareferens för Azure Files Monitoring.

Klienten kan inte uppnå maximalt dataflöde som stöds av nätverket

Orsak

En möjlig orsak är bristen på SMB-stöd för flera kanaler för standardfilresurser. För närvarande stöder Azure Files endast en kanal för standardfilresurser, så det finns bara en anslutning från den virtuella klientdatorn till servern. Den här enkla anslutningen är kopplad till en enda kärna på den virtuella klientdatorn, så det maximala dataflöde som kan uppnås från en virtuell dator är bundet av en enda kärna.

Lösning

• Aktivera SMB Multichannel för Premium-filresurser.
• Om du skaffar en virtuell dator med en större kärna kan du förbättra dataflödet.
• Om du kör klientprogrammet från flera virtuella datorer ökar dataflödet.
• Använd REST-API:er där det är möjligt.
• För NFS Azure-filresurser nconnect är tillgängligt. Se Förbättra prestanda för NFS Azure-filresurs med nconnect.

Dåliga prestanda för en Azure-filresurs monterad i en virtuell Linux-dator

Orsak 1: Cachelagring

En möjlig orsak till långsamma prestanda är inaktiverad cachelagring. Cachelagring kan vara användbart om du kommer åt en fil upprepade gånger. Annars kan det vara ett omkostnader. Kontrollera om du använder cachen innan du inaktiverar den.

Lösning för orsak 1

Om du vill kontrollera om cachelagring är inaktiverat letar du efter posten cache= .

Cache=none anger att cachelagring är inaktiverat. Montera om resursen med standardmonteringskommandot eller genom att uttryckligen cache=strict lägga till alternativet i monteringskommandot för att säkerställa att standardläget för cachelagring eller "strikt" cachelagring är aktiverat.

I vissa scenarier serverino kan monteringsalternativet ls göra att kommandot körs stat mot varje katalogpost. Det här beteendet resulterar i prestandaförsämring när du listar en stor katalog. Du kan kontrollera monteringsalternativen i din /etc/fstab-post :

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

Du kan också kontrollera om rätt alternativ används genom att köra sudo mount | grep cifs kommandot och kontrollera dess utdata. Följande är ett exempel på utdata:

//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 Om alternativet eller serverino inte finns demonterar och monterar du Azure Files igen genom att köra monteringskommandot från dokumentationen. Kontrollera sedan på nytt att posten /etc/fstab har rätt alternativ.

Orsak 2: Begränsning

Det är möjligt att du upplever begränsningar och att dina begäranden skickas till en kö. Du kan verifiera detta genom att använda Azure Storage-mått i Azure Monitor. Du kan också skapa aviseringar som meddelar dig om en resurs begränsas eller håller på att begränsas. Se Felsöka Azure Files genom att skapa aviseringar.

Lösning för orsak 2

Se till att din app ligger inom Azure Files-skalningsmålen. Om du använder azure-standardfilresurser kan du byta till Premium.

Dataflödet på Linux-klienter är lägre än för Windows-klienter

Orsak

Det här är ett känt problem med att implementera SMB-klienten i Linux.

Lösning

• Sprid belastningen över flera virtuella datorer.
• På samma virtuella dator använder du flera monteringspunkter med ett nosharesock alternativ och sprider belastningen över dessa monteringspunkter.
• På Linux kan du prova att montera med ett nostrictsync alternativ för att undvika att tvinga fram en SMB-tömning vid varje fsync anrop. För Azure Files stör det här alternativet inte datakonsekvensen, men det kan resultera i inaktuella filmetadata i kataloglistor (ls -l kommando). Om du direkt frågar efter filmetadata med hjälp stat av kommandot returneras de senaste filmetadata.

Långa svarstider för metadataintensiva arbetsbelastningar som omfattar omfattande öppna/stänga åtgärder

Orsak

Brist på stöd för kataloglån.

Lösning

• Undvik om möjligt att använda ett överdrivet öppet/avslutande handtag i samma katalog inom en kort tidsperiod.
• För virtuella Linux-datorer ökar du tidsgränsen för katalogpostens cache genom att actimeo=<sec> ange som ett monteringsalternativ. Som standard är tidsgränsen 1 sekund, så ett större värde, till exempel 30 sekunder, kan hjälpa.
• För virtuella CentOS Linux- eller Red Hat Enterprise Linux-datorer (RHEL) uppgraderar du systemet till CentOS Linux 8.2 eller RHEL 8.2. Uppgradera kerneln till 5.0 eller senare för andra Linux-distributioner.

Långsam uppräkning av filer och mappar

Orsak

Det här problemet kan uppstå om det inte finns tillräckligt med cacheminne på klientdatorn för stora kataloger.

Lösning

Lös problemet genom att justera DirectoryCacheEntrySizeMax registervärdet för att tillåta cachelagring av större kataloglistor på klientdatorn:

• Plats: HKEY_LOCAL_MACHINE\System\CCS\Services\Lanmanworkstation\Parameters
• Värdenamn: DirectoryCacheEntrySizeMax
• Värdetyp: DWORD

Du kan till exempel ange det till 0x100000 och se om prestandan förbättras.

Långsam filkopiering till och från Azure-filresurser

Du kan se långsamma prestanda när du försöker överföra filer till Azure Files-tjänsten. Om du inte har ett specifikt minsta I/O-storlekskrav rekommenderar vi att du använder 1 MiB som I/O-storlek för optimal prestanda.

Överdriven katalogÖppna/KatalogClose-anrop

Orsak

Om antalet DirectoryOpen/DirectoryClose-anrop är bland de främsta API-anropen och du inte förväntar dig att klienten ska göra så många anrop kan problemet orsakas av antivirusprogrammet som är installerat på den virtuella Azure-klientdatorn.

Lösning

En korrigering för det här problemet finns i April Platform Update för Windows.

SMB Multichannel utlöses inte

Orsak

De senaste ändringarna av konfigurationsinställningarna för SMB Multichannel utan återmontering.

Lösning

• Efter ändringar i konfigurationsinställningarna för Windows SMB-klienten eller kontotSMB multichannel måste du demontera resursen, vänta i 60 sekunder och montera om resursen för att utlösa multichannel.
• För Windows-klientoperativsystem genererar du I/O-belastning med högt ködjup, t.ex. QD=8, till exempel kopiera en fil för att utlösa SMB Multichannel. För serveroperativsystem utlöses SMB Multichannel med QD=1, vilket innebär att så fort du startar någon I/O till resursen.

Långsamma prestanda när filer packas upp

Beroende på vilken komprimeringsmetod och uppackningsåtgärd som används kan dekomprimeringsåtgärder utföras långsammare på en Azure-filresurs än på din lokala disk. Detta beror ofta på att uppackingsverktyg utför ett antal metadataåtgärder i processen för att utföra dekomprimering av ett komprimerat arkiv. För bästa prestanda rekommenderar vi att du kopierar det komprimerade arkivet från Azure-filresursen till din lokala disk, packa upp det och sedan använda ett kopieringsverktyg som Robocopy (eller AzCopy) för att kopiera tillbaka till Azure-filresursen. Om du använder ett kopieringsverktyg som Robocopy kan du kompensera för den minskade prestandan för metadataåtgärder i Azure Files i förhållande till din lokala disk genom att använda flera trådar för att kopiera data parallellt.

Långa svarstider på webbplatser som finns på filresurser

Orsak

Meddelande om filändring med högt antal filer på filresurser kan resultera i långa svarstider. Detta inträffar vanligtvis med webbplatser som finns på filresurser med djup kapslad katalogstruktur. Ett vanligt scenario är IIS-värdbaserade webbprogram där avisering om filändring har konfigurerats för varje katalog i standardkonfigurationen. Varje ändring (ReadDirectoryChangesW) på resursen som klienten är registrerad för skickar ett ändringsmeddelande från filtjänsten till klienten, som tar systemresurser, och problemet förvärras med antalet ändringar. Detta kan orsaka resursbegränsning och därmed leda till högre svarstid på klientsidan.

För att bekräfta kan du använda Azure Metrics i portalen.

1. Gå till ditt lagringskonto i Azure-portalen.
2. I den vänstra menyn, under Övervakning, väljer du Mått.
3. Välj Arkiv som måttnamnområde för lagringskontots omfång.
4. Välj Transaktioner som mått.
5. Lägg till ett filter för ResponseType och kontrollera om några begäranden har en svarskod SuccessWithThrottling för (för SMB eller NFS) eller ClientThrottlingError (för REST).

Lösning

• Om meddelandet om filändring inte används inaktiverar du meddelandet om filändring (rekommenderas).

  • Inaktivera meddelande om filändring genom att uppdatera FCNMode.
  • Uppdatera avsökningsintervallet för IIS-arbetsprocessen (W3WP) till 0 genom att ange HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\W3SVC\Parameters\ConfigPollMilliSeconds i registret och starta om W3WP-processen. Mer information om den här inställningen finns i Vanliga registernycklar som används av många delar av IIS.

• Öka frekvensen för avsökningsintervallet för filändringsmeddelanden för att minska volymen.

  Uppdatera avsökningsintervallet för W3WP-arbetsprocessen till ett högre värde (till exempel 10 eller 30 minuter) baserat på dina behov. Ange HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\W3SVC\Parameters\ConfigPollMilliSeconds i registret och starta om W3WP-processen.

• Om webbplatsens mappade fysiska katalog har en kapslad katalogstruktur kan du försöka begränsa omfånget för filändringsmeddelanden för att minska meddelandevolymen. Som standard använder IIS konfiguration från Web.config-filer i den fysiska katalog som den virtuella katalogen mappas till, samt i eventuella underordnade kataloger i den fysiska katalogen. Om du inte vill använda Web.config-filer i underordnade kataloger anger du false attributet för allowSubDirConfig den virtuella katalogen. Mer information finns här.

  Ange inställningen för den virtuella IIS-katalogen allowSubDirConfig i Web.Config så att false mappade fysiska underordnade kataloger undantas från omfånget.

Se även

• Felsök Azure Files
• Felsöka Azure Files genom att skapa aviseringar
• Förstå Prestanda för Azure Files
• Översikt över aviseringar i Microsoft Azure
• Vanliga frågor och svar om Azure Files

Kontakta oss om du behöver hjälp

Om du har frågor eller behöver hjälp skapar du en supportbegäran eller frågar Azure Community-support. Du kan också skicka produktfeedback till Azure-feedbackcommunityn.