Share via

Felsöka Azure Files prestandaproblem

  • Artikel

Obs!

CentOS som refereras i den här artikeln är en Linux-distribution och kommer att nå End Of Life (EOL). Överväg din användning och planera i enlighet med detta. Mer information finns i CentOS End Of Life-vägledning.

Den här artikeln innehåller vanliga problem som rör prestanda för Azure-filresurser och ger 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

Filresurstyp SMB NFS
Standardfilresurser (GPv2), LRS/ZRS
Standardfilresurser (GPv2), GRS/GZRS
Premium-filresurser (FileStorage), LRS/ZRS

Allmän prestandafelsökning

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

Du kör ett gammalt operativsystem

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

Överväganden för Windows 8.1 och Windows Server 2012 R2

Klienter som kör Windows 8.1 eller Windows Server 2012 R2 kan se en fördröjning som är högre än förväntat vid åtkomst till Azure-filresurser för I/O-intensiva arbetsbelastningar. Kontrollera att snabbkorrigeringen KB3114025 är installerad. Den här snabbkorrigeringen förbättrar prestandan för att skapa och stänga referenser.

Du kan köra följande skript för att kontrollera om snabbkorrigeringen har installerats:

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

Om snabbkorrigeringen är installerad visas följande utdata:

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

Obs!

Windows Server 2012 R2-avbildningar i Azure Marketplace har snabbkorrigeringar KB3114025 installerade som standard, från och med december 2015.

Din arbetsbelastning begränsas

Begäranden begränsas när I/O-åtgärder per sekund (IOPS), ingress- eller utgående gränser för en filresurs nås. Om klienten till exempel överskrider IOPS-baslinjen 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 Filresurs- och filskalningsmål. 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.

Långa svarstider, 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.

Viktigt

För standardlagringskonton sker begränsning på lagringskontonivå. För premiumfilresurser sker begränsning på resursnivå.

  1. Gå till ditt lagringskonto i Azure Portal.

  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
    • ClientAccountBandwidthrottlingError

    För premiumfilresurser 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.

    Skärmbild som visar egenskapsfiltret Svarstyp.

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. I 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.

Skärmbild som visar egenskapsfiltret

Workarounds

  • 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 i 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 med enskild skrivare/läsare eller scenarier med flera läsare och inga skrivare. Eftersom filsystemet ägs av klienten i stället för att 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 Portal.

    1. Från datorn som behöver åtkomst till 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 är mappad till, ange Virtuell hårddiskstorlek 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 Utforskaren 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: standardnätverksmappningen för Azure-filresursen på Z:, och VHD-mappningen på E:-enheten.
    8. Det bör finnas mycket bättre prestanda för 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 det program som du använder är entrå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 det totala antalet kanaler inte överskrider fyra. Om du till exempel har två nätverkskort kan du ange maxvärdet per nätverkskort till två med hjälp av följande PowerShell-cmdlet: Set-SmbClientConfiguration -ConnectionCountPerRssNetworkInterface 2.

Orsak 5: Läs-före-storlek är för liten (endast NFS)

Från och med Linux kernel version 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 read-ahead-storleken beständigt genom att lägga till en regel i udev, en Linux-kernelenhetshanterare. Gör så här:

  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ång svarstid 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 läser du transaktionsmåtten SuccessE2ELatency och SuccessServerLatency via Azure Monitor i Azure Portal. En stor skillnad mellan måttvärdena SuccessE2ELatency och SuccessServerLatency är en indikation på svarstid som troligen orsakas av nätverket eller klienten. Se Transaktionsmått i referensen för Azure Files Övervakningsdata.

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 enda 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.

Långsamma prestanda för en Azure-filresurs som monterats på 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 använder 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 fall kan monteringsalternativet serverinols 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 posten /etc/fstab :

//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 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ål. Om du använder azure-standardfilresurser kan du överväga att 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 -lkommando). 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äng-åtgärder

Orsak

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

Lösning

  • Undvik om möjligt att använda ett överdrivet öppnings-/stängningshandtag 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 Datorer med CentOS Linux eller Red Hat Enterprise Linux (RHEL) uppgraderar du systemet till CentOS Linux 8.2 eller RHEL 8.2. För andra Linux-distributioner uppgraderar du kerneln till 5.0 eller senare.

Långsam uppräkning av filer och mappar

Orsak

Det här problemet kan inträffa 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.

Långsam filkopiering till och från Azure Files i Windows

  • Om du vet den slutliga storleken på en fil som du utökar med skrivningar och programvaran inte har kompatibilitetsproblem när den oskrivna svansen på filen innehåller nollor, anger du filstorleken i förväg i stället för att göra varje skrivning till en utökad skrivning.

  • Använd rätt kopieringsmetod:

    • Använd AzCopy för alla överföringar mellan två filresurser.
    • Använd Robocopy mellan filresurser på en lokal dator.

Överdriven katalogÖppna/KatalogSluta 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 bero på antivirusprogrammet som är installerat på den virtuella Azure-klientdatorn.

Lösning

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

SMB Multichannel utlöses inte

Orsak

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

Lösning

  • När du har ändrat konfigurationsinställningarna för Windows SMB-klienten eller kontots SMB 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 en I/O till resursen.

Långsamma prestanda vid uppackning av filer

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 filändringsmeddelandet 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 svarstider på klientsidan.

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

  1. Gå till ditt lagringskonto i Azure Portal.
  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 svarskoden SuccessWithThrottling (för SMB eller NFS) eller ClientThrottlingError (för REST).

Lösning

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

  • Ö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\ConfigPollMilliSecondsi 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 alla underordnade kataloger i den fysiska katalogen. Om du inte vill använda Web.config filer i underordnade kataloger anger du false för allowSubDirConfig attributet i den virtuella katalogen. Mer information finns här.

    Ange inställningen för virtuell IIS-katalog allowSubDirConfig i Web.Config för att false undanta mappade fysiska underordnade kataloger från omfånget.

Se även

Kontakta oss för att få hjälp

Om du har frågor eller behöver hjälp skapar du en supportförfrågan eller frågar Azure community support. Du kan också skicka produktfeedback till Azure-feedbackcommunityn.