MSSQLSERVER_17890

Gäller för:SQL Server

Detaljer

Attribute Value
Produktnamn SQL Server
Händelse-ID 17890
Händelsekälla MSSQLSERVER
Komponent SQLEngine
Symboliskt namn SRV_WS_TRIMMED
Meddelandetext En betydande del av SQL Server-processminnet har radats ut. Detta kan leda till en prestandaförsämring. Varaktighet: %d sekunder. Arbetsuppsättning (KB): %I64d, bekräftad (KB): %I64d, minnesanvändning: %d%%.

Explanation

Du kan stöta på följande felmeddelande i SQL Server-felloggen eller Windows-applikationens händelselogg.

En betydande del av SQL Server-processminnet har radats ut. Detta kan leda till en prestandaförsämring. Varaktighet: 0 sekunder. Arbetsmängd (KB): 3383250, committed (KB): 9112480, minnesanvändning: 37%.

Du kan också märka en plötslig prestandaförsämring vid körning av frågor och alla andra operationer på SQL Server.

Orsak

SQL Server övervakar olika minnesrelaterade uppgifter om SQL Server-processen. I detta fall har den upptäckt att processens arbetsmängd är mindre än 50% av det engagerade processminnet. Som ett resultat skrivs denna varning ut. De normala orsakerna till denna varning är:

  • Operativsystemet blottlägger ut stora delar av SQL Server-dedikerat minne till sidfilen.
  • Detta kan bero på plötslig ökad minnesefterfrågan från andra applikationer eller operativsystembehov.
  • Detta kan också hända när vissa drivrutiner begär sammanhängande minnesallokeringar för sina behov.

Användaråtgärd

Du kan förhindra att Windows-operativsystemet plockar ut buffertpoolminnet i SQL Server-processen genom att låsa det minne som är avsatt för buffertpoolen i det fysiska minnet. Du låser minnet genom att tilldela Lock pages in memory-användaren till det användarkonto som används som startkonto för SQL Server-tjänsten. Men innan du implementerar denna lösning, granska avsnitten Vad som gör att SQL Server-minnet bläddras ut och Viktiga överväganden innan du tilldelar användarrätten "Lås sidor i minnet" för en instans av SQL Server

Note

Genom att använda Lock Pages in Memory säkerställer du att minnet som hanteras av SQL Server inte blir utväxlet. Dock kan trådstackar, EXE och eventuella DLL-bilder, heapminne och CLR-minne fortfarande pages ut av operativsystemet.

Från och med SQL Server 2008 SP1 Cumulative Update 2 kan både SQL Server Standard och Enterprise editionerna använda Lock-sidorna i minnet till användarens rättigheter. För mer information om stöd för låsta sidor, se KB970070 - Stöd för låsta sidor på SQL Server Standard Edition (64-bitars) system.

För att tilldela Lock-sidorna i minnet till användarhöger, följ dessa steg:

  1. Klicka på Start, välj Kör, skriv gpedit.msc och klicka sedan på OK.
  2. Observera: Dialogrutan för gruppolicy visas.
  3. Expandera Datorkonfiguration och sedan Windows inställningar.
  4. Expandera säkerhetsinställningar och sedan Lokala policys.
  5. Klicka på Användarrättighetstilldelning och dubbelklicka sedan på Lås sidor i minnet.
  6. I dialogrutan Lokal säkerhetspolicyinställning , klicka på Lägg till användare eller grupp.
  7. I dialogrutan Välj användare eller grupper, lägg till det konto som har behörighet att köra Sqlservr.exe-filen och klicka sedan på OK.
  8. Stäng dialogrutan för grupppolicy .
  9. Starta om SQL Server-tjänsten.

Efter att du tilldelar användaren Lock Pages in Memory och startar om SQL Server-tjänsten, så bipplar inte Windows-operativsystemet längre ut buffertpoolminnet i SQL Server-processen. Dock kan operativsystemet Windows fortfarande plocka ut icke-buffertpoolminnet inom SQL Server-processen.

Du kan verifiera att användarrätten används av instansen av SQL Server genom att se till att följande meddelande är skrivet i SQL Server Error Log vid uppstart: "Använder låsta sidor för buffer pool"

Detta meddelande gäller endast för SQL Server. För mer information om detta meddelande i ERRORLOG, besök följande: Måste jag tilldela låssidorna för minnesprivilegier i Local System

När Windows-operativsystemet tar ut minnet från icke-buffertpoolen kan du fortfarande stöta på prestandaproblem. Dock loggas inte felmeddelandena som nämns i avsnittet "Förklaring" i SQL Server fellogg.

Vad orsakar att SQL Server-minnet blir utdraget

Det finns tre breda kategorier av problem som kan orsaka detta problem:

  • Application-Related Problem: Alla applikationer tillsammans har uttömt det tillgängliga fysiska minnet och operativsystemet måste frigöra minne för nya applikationsförfrågningar om resurser. Vanligtvis är tillvägagångssättet här att hitta vilka applikationer som förbrukar minnet och vidta nödvändiga åtgärder för att balansera minnet mellan dem utan att det leder till RAM-uttömning.
  • Problem med enhetsdrivrutiner: Enhetsdrivrutiner kan orsaka fungerande set-paging av alla processer om drivrutinen anropar en minnesallokeringsfunktion felaktigt.
  • Problem med operativsystemet

Nedan hittar du information om var och en av dessa kategorier

  • Application-Related problem: Applikationer tillsammans kan förbruka allt RAM på systemet. Om nya minnesförfrågningar görs försöker operativsystemet tillfredsställa dem och om det inte finns något ledigt minne kommer det att trimma arbetsuppsättningen av körande applikationer för att uppfylla minnesförfrågningarna. I sådana fall kan du märka att arbetsmängden för de flesta, om inte alla, applikationer minskar avsevärt. För att observera detta, samla in följande Performance Monitor-räknare för alla applikationer på systemet:

    • Prestandaobjekt: Process
    • Räknare: Arbetsset

    Övervaka också följande räknare för att korrelera hur mycket fysiskt minne som finns tillgängligt på systemet.

    • Prestandaobjekt: Minne
    • Räknare: Tillgängligt minne (MB)

    Det typiska beteendet du kan observera är en minskning av tillgängligt minne nära 0 MB samtidigt som en plötslig minskning av arbetsuppsättningsräknarna för de flesta (alla) processer i systemet inträffar. Om du observerar ett sådant beteende kan du behöva vidta åtgärder för att minska minnesanvändningen på systemet, vilket till exempel inkluderar att minska Max Server-minne för SQL Server.

    Applikationer kan också använda systemcachen för mycket och orsaka en stor tillväxt av systemcachen. För att möta tillväxten av systemcachen bliederar systemet ut arbetsuppsättningen för SQL Server-processen eller andra applikationer. Om du upplever detta problem kan du använda vissa minneshanteringsfunktioner i applikationen. Dessa funktioner styr det cacheutrymme som fil-I/O-operationer kan använda i applikationen. Till exempel kan du använda funktionen SetSystemFileCacheSize och funktionen GetSystemFileCacheSize för att styra det systemcacheutrymme som fil-I/O-operationer kan använda.

    Du kan använda objektet Memory performance för att se värdena för olika räknare i detta objekt för att avgöra om systemcachens arbetsmängd använder för mycket minne. Till exempel kan du se räknarna för Cache Bytes och System Cache Resident Bytes. För mer information om detta ämne, se:

    Du kan ladda ner och distribuera "Microsoft Windows Dynamic Cache Service" för att styra det minne som förbrukas av systemcachen.

  • Drivrutinsproblem: Om en enhetsdrivrutin använder MmAllocateContiguousMemory funktionen, och om den sätter värdet på parametern HighestAcceptableAddress till mindre än 4 gigabyte (GB), kan Windows-operativsystemet page ut arbetsmängden av processerna på systemet, inklusive SQL Server-processen. För att lösa detta problem, kontakta leverantören av enhetsdrivrutinen för drivrutinsuppdateringar.

    När en enhetsdrivrutin försöker allokera minne kan operativsystemet Windows plocka ut arbetsmängden för andra applikationer. Denna Windows-hotfix låter dig använda händelsespårning för att hitta enhetsdrivrutinen som orsakar problemet. För att hitta mer information om den specifika drivrutin som orsakar funktionssättningsbeteendet, se Identifiering av drivrutiner som tilldelar sammanhängande minne.

  • Operativsystemsproblem: För att lösa de kända problem som gör att Windows-operativsystemet blädrar ut arbetsuppsättningen för SQL Server-processen, tillämpa de snabbfixar som beskrivs i följande artiklar i Microsoft Knowledge Base.

    Note

    Hotfixes är kumulativa. En senare version av en hotfix innehåller de tidigare versionerna av den hotfixen.

Viktiga överväganden innan du tilldelar användarrätten "Lås sidor i minnet"

Du bör göra ytterligare överväganden innan du tilldelar användarrättigheterna för Lock-sidorna i minnet. Om du tilldelar denna användare rätt på system som är fel konfigurerade kan systemet bli instabilt eller uppleva en prestandaförsämring för hela systemet. Dessutom kan händelse-ID 333 loggas i händelseloggen.

Om du kontaktar Microsoft Customer Support Service (CSS) för dessa problem kan CSS-ingenjörer be dig att återkalla denna användarrätt för det användarkonto som används som startkonto för SQL Server-tjänsten. Detta steg kan vara nödvändigt för att samla in viktig prestandadata som CSS-ingenjörer kan använda för nödvändig konfiguration av de olika alternativen för SQL Server och för andra applikationer som körs på systemet. Efter att CSS-ingenjörer samlat in prestandadata kan du tilldela Lock Pages in Memory-användaren direkt till startkontot för SQL Server-tjänsten.

Innan du tilldelar användaren Lock Pages in Memory, se till att du samlar in en Performance Monitor-logg för att fastställa minnesbehoven för olika applikationer och tjänster som är installerade på systemet. Dessa applikationer inkluderar även SQL Server. För att fastställa minneskraven, samla in följande grundläggande information:

  • Se till att du ställer in alternativet för maximalt serverminne och minimum serverminne korrekt. Dessa alternativ speglar endast minnesbehovet i buffertpoolen för SQL Server-processen. Dessa alternativ inkluderar inte det minne som är allokerat för andra komponenter inom SQL Server-processen. Dessa komponenter inkluderar följande:

    • SQL Server-arbetstrådarna
    • Olika DLL:er och komponenter som SQL Server bearbetar laddar inom adressutrymmet för SQL Server-processen
    • Backup- och återställningsoperationerna

  • DLL:erna och komponenterna inkluderar olika OLE DB-leverantörer, utökade lagrade procedurer Microsoft COM-objekt som används för sp_OACreate lagrad procedur, länkade servrar och SQL Server CLR. Det minne som är allokerat för dessa komponenter tillhör icke-buffertpool-regionen i adressutrymmet för SQL Server-processen. För att idealiskt bestämma den maximala mängden minne som hela SQL Server-processen kan använda, måste du dra av det minne som är allokerat för komponenter som inte använder buffertpoolen från det totala minne du vill att SQL Server-processen ska använda. Sedan kan du använda restvärdet för att ställa in alternativet för maximalt serverminne. Innan du sätter alternativet för maximalt serverminne och alternativet för minsta serverminne bör du noggrant granska ämnet "Manuellt ställa in minnesalternativen" i SQL Server Books Online.

  • Bestäm minnesbehovet för andra applikationer och för Windows-operativsystemets komponenter. Applikationer kan inkludera andra SQL Server-komponenter, till exempel SQL Server Agent, SQL Server Replication Agents, SQL Server Reporting Services, SQL Server Analysis Services, služba SSIS och SQL Server fulltextsökning. Program som utför säkerhetskopierings- och filkopieringsoperationer kan använda många minnen. Tänk på operationer som bulkkopiering och Snapshot Agent som genererar fil-IO. Du måste ta hänsyn till minnesbehovet för alla dessa applikationer när du bestämmer värdet på maximala serverminnesalternativet och minimum serverminnesalternativet. Du kan använda Private Bytes-räknaren och Working Set-räknaren under Process-objektet för varje process för att bestämma minnesbehovet för en specifik process.

  • Som standard har låssidorna i minnesanvändaren redan tilldelats det inbyggda Local System-kontot. För mer information, besök följande Microsoft-webbplats: Måste jag tilldela Lock-sidor i minnesbehörighet för lokalt system?

  • Om du använder ett Windows-användarkonto globalt för alla SQL Server-processer i en domän, bestäm vilka användarrättigheter som tilldelas genom att använda en grupppolicykonfiguration. En 32-bitars SQL Server-process kan använda detta konto som startkonto. Detta konto kräver dock användarrättigheterna Lock pages in memory för att aktivera Address Windowing Extensions (AWE)-funktionen. För mer information, se ämnet "Providing the most amount of memory to SQL Server" i SQL Server Books Online.

  • Innan du konfigurerar alternativet för maximalt serverminne och alternativet för minsta serverminne för flera SQL Server-instanser, överväg minneskraven för icke-buffertpoolen för varje instans av SQL Server. Konfigurera sedan dessa alternativ för varje instans av SQL Server.

Idealiskt samlar du in denna baslinjeinformation under toppbelastningar. Därför kan du bestämma minneskraven för olika applikationer och komponenter för att stödja toppbelastningen. Minneskraven varierar från ett system till ett annat, beroende på aktiviteterna och applikationerna som körs på systemet. Du kan fråga informationen som ges i den dynamiska hanteringsvyn sys.dm_os_process_memory för att förstå om systemet har låga minnesförhållanden. För mer information, se sys.dm_os_process_memory (Transact-SQL).

Förbättringar tillagda i Windows Server 2008 och R2-versionen

Windows Server 2008 och Windows Server 2008 R2 förbättrar mekanismen för sammanhängande minnesallokering. Denna förbättring gör att Windows Server 2008 och Windows Server 2008 R2 till viss del kan minska effekterna av att placera ut arbetsmängden av applikationer när nya minnesförfrågningar anländer.

Följande är en förklaring av förbättringarna från Microsoft:s whitepaper "Advances in Memory Management in Windows":

I Windows Server 2008 är tilldelningen av fysiskt sammanhängande minne kraftigt förbättrad. Förfrågningar om att allokera sammanhängande minne är mycket mer sannolika att lyckas eftersom minneshanteraren nu dynamiskt byter sidor, vanligtvis utan att trimma arbetsmängden eller utföra I/O-operationer. Dessutom är många fler typer av sidor – såsom kärnstackar och filsystemmetadatasidor, bland andra – nu kandidater för ersättning. Följaktligen finns mer sammanhängande minne i allmänhet tillgängligt vid varje given tidpunkt. Dessutom minskar kostnaden för att få sådana tilldelningar avsevärt.

För mer information, se SQL Server Working Set Trim Problems.

De produkter från tredje part som beskrivs i den här artikeln tillverkas av företag som är oberoende av Microsoft. Microsoft ger ingen garanti, uttrycklig eller underförstådd, angående prestandan eller tillförlitligheten hos dessa produkter.

  • Last updated on