Felsöka prestandaproblem hos Azure-filresurser

  • Artikel
  • 12 minuter för att läsa

Den här artikeln innehåller några vanliga problem som rör Azure-filresurser. Den innehåller möjliga orsaker och lösningar för när du stöter på dessa problem.

Gäller för

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

Höga svarstider, lågt dataflöde och allmänna prestandaproblem

Orsak 1: Resursen har begränsats

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. Information om gränserna för standard- och premiumfilresurser finns i Filresurs- och filskalningsmål.

För att bekräfta om resursen begränsas kan du komma åt och använda Azure-mått i portalen.

  1. I Azure Portal du till ditt lagringskonto.

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

  3. Välj Arkiv som måttnamnrymd för ditt lagringskontoomfå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:

    • SuccessWithThrottling
    • SuccessWithShareIopsThrottling
    • ClientShareIopsThrottlingError

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

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

    Mer information om varje svarstyp finns i Måttdimensioner.

    Skärmbild av måttalternativen för premiumfilresurser med egenskapsfiltret "Svarstyp".

    Anteckning

    Information om hur du får en avisering finns i avsnittet "Så här skapar du en avisering om en filresurs begränsas" längre fram i den här artikeln.

Lösning

Orsak 2: Metadata eller namnområde – tung arbetsbelastning

Om de flesta av dina begäranden är metadatacentrerade (till exempel , , , eller ), blir svarstiden sämre än för createfile openfile closefile queryinfo querydirectory 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 enligt beskrivningen i Orsak 1. För steg 5 lägger du till ett egenskapsfilter för API-namnet i stället för att lägga till ett filter för Svarstyp.

Skärmbild av måttalternativen för premiumfilresurser med egenskapsfiltret "API-namn".

Lösning

  • Kontrollera om programmet kan ändras för att minska antalet metadataåtgärder.
  • 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 en enskild skrivare/läsare eller scenarier med flera läsare och inga skrivare. Eftersom filsystemet ägs av klienten i stället för Azure Files kan metadataåtgärderna vara lokala. Konfigurationen ger prestanda som liknar den för en lokal direktkopplad lagring.
    • Om du vill montera en virtuell hårddisk Windows en virtuell hårddiskklient använder du PowerShell-cmdleten Mount-DiskImage.
    • Om du vill montera en virtuell hårddisk i Linux kan du läsa dokumentationen för din Linux-distribution.

Orsak 3: Enkeltrådat program

Om programmet 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 programparallellitet genom att öka antalet trådar.
  • Växla till program där parallellitet är möjlig. 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 det 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 överstiger 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 .

Mycket lång svarstid för begäranden

Orsak

Den virtuella klientdatorn (VM) kan finnas i en annan region än filresursen. En annan orsak till hög latens kan bero på den fördröjning 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 Portal. En hög 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 Azure Files övervakningsdata.

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

Orsak

En möjlig orsak är brist på SMB-stöd för flera kanaler för standardfilresurser. För närvarande Azure Files endast en kanal, så det finns bara en anslutning från den virtuella klientdatorn till servern. Den här enskilda anslutningen är knuten 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

  • För premiumfilresurser aktiverar du SMB Multichannel.
  • Att hämta en virtuell dator med en större kärna kan förbättra dataflödet.
  • Om klientprogrammet körs från flera virtuella datorer ökar dataflödet.
  • Använd REST API:er där det är möjligt.
  • För NFS-filresurser är nconnect tillgängligt i förhandsversion. Rekommenderas inte för produktionsarbetsbelastningar.

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

Orsak

Det här är ett känt problem med implementeringen av SMB-klienten på Linux.

Lösning

  • Sprida belastningen över flera virtuella datorer.
  • På samma virtuella dator använder du flera monteringspunkter med nosharesock ett alternativ och sprider belastningen över dessa monteringspunkter.
  • I Linux kan du prova att montera med nostrictsync ett alternativ för att undvika att framtvinga SMB-flush vid varje fsync anrop. Det Azure Files här alternativet stör inte datakonsekvensen, men det kan resultera i inaktuella filmetadata i kataloglistor ( ls -l kommando). Om du kör direkta frågor mot stat filmetadata med kommandot returneras de mest aktuella filmetadata.

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

Orsak

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

Lösning

  • Om möjligt bör du undvika att använda en överdriven inledande/avslutande referens i samma katalog inom en kort tidsperiod.
  • För virtuella Linux-datorer ökar du tidsgränsen för katalogpostcache genom att actimeo=<sec> ange som ett monteringsalternativ. Som standard är tidsgränsen 1 sekund, så ett större värde, till exempel 3 eller 5 sekunder, kan vara till hjälp.
  • För virtuella CentOS Linux Red Hat Enterprise Linux(RHEL) datorer uppgraderar du systemet till CentOS Linux 8.2 eller RHEL 8.2. För andra virtuella Linux-datorer uppgraderar du kerneln till 5.0 eller senare.

Låg IOPS på CentOS Linux eller RHEL

Orsak

Ett I/O-djup som är större än 1 stöds inte på CentOS Linux eller RHEL.

Lösning

  • Uppgradera till CentOS Linux 8 eller RHEL 8.
  • Ändra till Ubuntu.

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

Om filkopiering går långsamt kan du se avsnittet "Långsam filkopiering till och från Azure-filresurser i Linux" i felsökningsguiden för Linux.

Jittery- eller sawtooth-mönster för IOPS

Orsak

Klientprogrammet överskrider konsekvent baslinje-IOPS. För närvarande finns det ingen utjämning av begärandebelastningen på tjänstsidan. Om klienten överskrider baslinje-IOPS begränsas den av tjänsten. Begränsningen kan resultera i att klienten upplever ett jittery- eller sågtands-IOPS-mönster. I det här fallet kan den genomsnittliga IOPS som uppnås av klienten vara lägre än baslinje-IOPS.

Lösning

  • Minska belastningen på begäran från klientprogrammet så att resursen inte begränsas.
  • Öka kvoten för resursen så att resursen inte begränsas.

Ö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 bero på det antivirusprogram som är installerat på den virtuella Azure-klientdatorn.

Lösning

Filskapandet går långsammare än förväntat

Orsak

Arbetsbelastningar som förlitar sig på att skapa ett stort antal filer ser ingen betydande skillnad i prestanda mellan premiumfilresurser och standardfilresurser.

Lösning

  • Inga.

Långsamma prestanda från Windows 8.1 eller Server 2012 R2

Orsak

Längre svarstider än förväntat vid åtkomst till Azure-filresurser för I/O-intensiva arbetsbelastningar.

Lösning

SMB Multichannel utlöses inte.

Orsak

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

Lösning

  • När du har gjort ändringar i SMB Windows klienten eller SMB-kontokonfigurationsinställningarna för flera kanaler måste du demontera resursen, vänta i 60 sekunder och återmontera 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, och kopierar till exempel en fil för att utlösa SMB Multichannel. För serveroperativsystemet utlöses SMB Multichannel med QD=1, vilket innebär att när du startar en I/O till resursen.

Hög svarstid på webbplatser som finns på filresurser

Orsak

Meddelande om filändring med högt antal på filresurser kan resultera i betydande höga svarstider. Detta inträffar vanligtvis med webbplatser som finns på filresurser med en djup kapslad katalogstruktur. Ett vanligt scenario är IIS-värdbaserade webbprogram där filändringsmeddelanden har ställts in för varje katalog i standardkonfigurationen. Varje ändring (ReadDirectoryChangesW) på resursen som klienten har registrerats för skickar ett ändringsmeddelande från filtjänsten till klienten, som tar systemresurser och utfärdar ändringar som är större än antalet ändringar. Detta kan orsaka resursbegränsning och därmed leda till längre svarstider på klientsidan.

För att bekräfta kan du använda Azure-mått i portalen –

  1. I Azure Portal du till ditt lagringskonto.
  2. I den vänstra menyn, under Övervakning, väljer du Mått.
  3. Välj Arkiv som måttnamnområde för ditt lagringskontoomfå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 (t.ex. 10 minuter 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 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 katalogen som den virtuella katalogen mappas till, samt i alla underordnade kataloger i den fysiska katalogen. Om du inte vill använda Web.config i underordnade kataloger anger du false för attributet allowSubDirConfig i den virtuella katalogen. Mer information finns här.
    • Ange inställningen "allowSubDirConfig" för den virtuella IIS-katalogen i Web.Config till false för att undanta mappade fysiska underordnade kataloger från omfånget.

Så här skapar du en avisering om en filresurs begränsas

  1. Gå till ditt lagringskonto i Azure Portal.

  2. I avsnittet Övervakning klickar du på Aviseringar och sedan på + Ny aviseringsregel.

  3. Klicka på Redigera resurs, välj Filresurstyp för lagringskontot och klicka sedan på Klar. Om lagringskontots namn till exempel contoso är väljer du resursen contoso/file .

  4. Klicka på Lägg till villkor för att lägga till ett villkor.

  5. Du ser en lista över signaler som stöds för lagringskontot och väljer måttet Transaktioner.

  6. På bladet Konfigurera signallogik klickar du på listrutan Dimensionsnamn och väljer Svarstyp.

  7. Klicka på listrutan Dimensionsvärden och välj lämpliga svarstyper för filresursen.

    För standardfilresurser väljer du följande svarstyper:

    • SuccessWithThrottling
    • SuccessWithShareIopsThrottling
    • ClientShareIopsThrottlingError

    För Premium-filresurser väljer du följande svarstyper:

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

    Anteckning

    Om svarstyperna inte visas i listrutan Dimensionsvärden innebär det att resursen inte har begränsats. Om du vill lägga till dimensionsvärdena bredvid listrutan Dimensionsvärden väljer du Lägg till anpassat värde, anger svarstypen (till exempel SuccessWithThrottling), väljer OK och upprepar sedan dessa steg för att lägga till alla tillämpliga svarstyper för filresursen.

  8. För premiumfilresurser klickar du på listrutan Dimensionsnamn och väljer Filresurs. För standardfilresurser går du vidare till steg 10.

    Anteckning

    Om filresursen är en standardfilresurs visar inte filresursdimensionen filresursen eftersom mått per resurs inte är tillgängliga för standardfilresurser. Begränsningsaviseringar för standardfilresurser utlöses om någon filresurs i lagringskontot begränsas och aviseringen inte identifierar vilken filresurs som har begränsats. Eftersom mått per resurs inte är tillgängliga för standardfilresurser rekommenderar vi att du har en filresurs per lagringskonto.

  9. Klicka på listrutan Dimensionsvärden och välj de filresurs(er) som du vill avisering om.

  10. Definiera aviseringsparametrarna (tröskelvärde, operator, sammansättningsdeklaritet och utvärderingsfrekvens) och klicka på Klar.

    Tips

    Om du använder ett statiskt tröskelvärde kan måttdiagrammet hjälpa dig att fastställa ett rimligt tröskelvärde om filresursen för närvarande begränsas. Om du använder ett dynamiskt tröskelvärde visar måttdiagrammet beräknade tröskelvärden baserat på senaste data.

  11. Klicka på Lägg till åtgärdsgrupper för att lägga till en åtgärdsgrupp (e-post, SMS osv.) i aviseringen genom att välja en befintlig åtgärdsgrupp eller skapa en ny åtgärdsgrupp.

  12. Fyll i aviseringsinformationen som Aviseringsregelnamn, Beskrivning och Allvarlighetsgrad.

  13. Klicka på Skapa aviseringsregel för att skapa aviseringen.

Mer information om hur du konfigurerar aviseringar Azure Monitor finns i Översikt över aviseringar i Microsoft Azure.

  1. I Azure Portal du till ditt lagringskonto.

  2. I avsnittet Övervakning väljer du Aviseringar och sedan Ny aviseringsregel.

  3. Välj Redigera resurs, välj Filresurstyp för lagringskontot och välj sedan Klar. Om lagringskontonamnet till exempel är contoso väljer du resursen contoso/file.

  4. Välj Välj villkor för att lägga till ett villkor.

  5. I listan över signaler som stöds för lagringskontot väljer du Egress måttet.

    Anteckning

    Du måste skapa tre separata aviseringar för att få aviseringar när de in- och utgående värdena eller transaktionsvärdena överskrider de tröskelvärden som du anger. Det beror på att en avisering endast utlöses när alla villkor är uppfyllda. Om du till exempel lägger till alla villkor i en avisering får du bara en avisering om ingress- och utgående transaktioner och transaktioner överskrider sina tröskelvärden.

  6. Rulla nedåt. I listrutan Dimensionsnamn väljer du Filresurs.

  7. I listrutan Dimensionsvärden väljer du den filresurs eller de resurser som du vill avisering om.

  8. Definiera aviseringsparametrarna genom att välja värden i listlistorna Operator, Threshold value(Operator, Tröskelvärde) , Aggregation granularity(Sammansättningsdeklaritet) och Frequency of evaluation (Utvärderingsfrekvens) och välj sedan Done (Klar).

    Egress måtten för ingress och transaktioner uttrycks per minut, även om du har etablerat utgående, ingress och I/O per sekund. Om din etablerade utgående utgående data exempelvis är 90 MiB/s och du vill att tröskelvärdet ska vara 80 procent av den etablerade utgående, väljer du   följande aviseringsparametrar:  

    • För Tröskelvärde: 75497472
    • För Operator: större än eller lika med
    • För Sammansättningstyp: genomsnitt

    Beroende på hur mycket brus du vill att aviseringen ska vara kan du även välja värden för Sammansättningskornighet och Utvärderingsfrekvens. Om du till exempel vill att aviseringen ska titta på den genomsnittliga ingressen under tidsperioden 1 timme och du vill att din aviseringsregel ska köras varje timme väljer du följande:

    • För Sammansättningskornighet: 1 timme
    • För Utvärderingsfrekvens: 1 timme

  9. Välj Lägg till åtgärdsgrupper och lägg sedan till en åtgärdsgrupp (till exempel e-post eller SMS) i aviseringen genom att välja en befintlig åtgärdsgrupp eller genom att skapa en ny.

  10. Ange aviseringsinformationen, till exempel Aviseringsregelnamn, Beskrivning och Allvarlighetsgrad.

  11. Välj Skapa aviseringsregel för att skapa aviseringen.

    Anteckning

    • Om du vill få ett meddelande om att premiumfilresursen är nära att begränsas på grund av en etablerad ingress följer du instruktionerna ovan, men med följande ändring:

      • I steg 5 väljer du måttet Ingress i stället för Egress.

    • Om du vill få ett meddelande om att premiumfilresursen är nära att begränsas på grund av etablerade IOPS följer du instruktionerna ovan, men med följande ändringar:

      • I steg 5 väljer du måttet Transaktioner i stället för Egress.
      • I steg 10 är det enda alternativet för Sammansättningstyp Total. Därför beror tröskelvärdet på den valda aggregeringskornigheten. Om du till exempel vill att tröskelvärdet ska vara 80 procent av den etablerade baslinjens IOPS och du väljer 1 timme för Sammansättningskornighet blir ditt tröskelvärde   baslinje-IOPS (i byte) ×   0,8 ×   3600.

Mer information om hur du konfigurerar aviseringar Azure Monitor finns i Översikt över aviseringar i Microsoft Azure.

Se även