Dela via

Arkitekturguide för minneshantering

gäller för:SQL ServerAzure SQL DatabaseAzure SQL Managed InstanceAzure Synapse AnalyticsAnalytics Platform System (PDW)

Windows Virtual Memory Manager

De incheckade regionerna i adressutrymmet mappas till det tillgängliga fysiska minnet av Windows Virtual Memory Manager (VMM).

Mer information om mängden fysiskt minne som stöds av olika operativsystem finns i Windows-dokumentationen om minnesgränser för Windows-versioner.

Virtuella minnessystem tillåter överåtagande av fysiskt minne, så att förhållandet mellan virtuellt och fysiskt minne kan överstiga 1:1. Därför kan större program köras på datorer med olika fysiska minneskonfigurationer. Men om du använder betydligt mer virtuellt minne än de kombinerade genomsnittliga arbetsuppsättningarna för alla processer kan det orsaka dåliga prestanda.

SQL Server-minnesarkitektur

SQL Server hämtar och frigör minne dynamiskt efter behov. Vanligtvis behöver en administratör inte ange hur mycket minne som ska allokeras till SQL Server, även om alternativet fortfarande finns och krävs i vissa miljöer.

Ett av de främsta designmålen för all databasprogramvara är att minimera disk-I/O eftersom diskläsningar och skrivningar är bland de mest resursintensiva åtgärderna. SQL Server skapar en buffertpool i minnet för att lagra sidor som lästs från databasen. Mycket av koden i SQL Server är dedikerad för att minimera antalet fysiska läsningar och skrivningar mellan disken och buffertpoolen. SQL Server försöker nå en balans mellan två mål:

  • Håll buffertpoolen från att bli så stor att hela systemet har ont om minne.
  • Minimera fysisk I/O till databasfilerna genom att maximera storleken på buffertpoolen.

I ett kraftigt belastat system kan vissa stora frågeställningar som kräver en stor mängd minne för att köras inte få den minsta mängden begärt minne och får ett timeout-fel medan de väntar på minnesresurser. Lös problemet genom att öka frågeväntealternativet. För en parallell fråga bör du överväga att minska den maximala graden av parallellitetsalternativ.

I ett kraftigt belastat system under minnesbelastning kan frågor med sammanslagningskoppling, sortering och bitmapp i frågeplanen släppa bitmappen när frågorna inte får det minimi minne som krävs för bitmappen. Detta kan påverka frågeprestandan och om sorteringsprocessen inte får plats i minnet kan den öka användningen av arbetstabeller i tempdb databasen, vilket gör tempdb att den växer. Lös problemet genom att lägga till fysiskt minne eller finjustera frågorna för att använda en annan och snabbare frågeplan.

Konventionellt (virtuellt) minne

Alla SQL Server-utgåvor stöder konventionellt minne på 64-bitarsplattform. SQL Server-processen kan komma åt virtuellt adressutrymme upp till operativsystemets högsta i x64-arkitekturen (SQL Server Standard Edition stöder upp till 128 GB). Med IA64-arkitekturen var gränsen 7 TB (IA64 stöds inte i SQL Server 2012 (11.x) och senare versioner). Mer information finns i Minnesgränser för Windows .

Hantera AWE (Windows-utvidgningar) minne

Med hjälp av AWE (Address Windowing Extensions ) och lpim-behörigheten ( Lock pages in memory ) som krävs av AWE kan du hålla det mesta av SQL Server-processminnet låst i fysiskt RAM-minne under förhållanden med lågt virtuellt minne. Detta sker i både 32- och 64-bitars AWE-allokeringar. Låsning av minne sker eftersom AWE-minne inte går via Windows Virtual Memory Manager, som hanterar paginering av minne. AWE-programmeringsgränssnittet för minnesallokering kräver behörigheten Lås sidor i minnet (SeLockMemoryPrivilege); se anteckningar för AllocateUserPhysicalPages. Därför är den största fördelen med att använda AWE-API:et att behålla det mesta av minnet i RAM-minnet om det finns minnestryck på systemet. Information om hur du tillåter att SQL Server använder AWE finns i Aktivera alternativet Lås sidor i minnet (Windows).

Om LPIM beviljas rekommenderar vi starkt att du anger maximalt serverminne (MB) till ett specifikt värde, i stället för att lämna standardvärdet 2 147 483 647 MEGABYTE (MB). Mer information finns i Server Memory Server Configuration: Ange alternativ manuellt och Lås sidor i minnet (LPIM).

Om LPIM inte är aktiverat växlar SQL Server till att använda konventionellt minne och i händelse av os-minnesöverbelastning och felet [MSSQLSERVER_17890] (errors-events/mssqlserver-17890-database-engine-error.md) kan rapporteras i felloggen. Felet liknar följande exempel:

A significant part of SQL Server process memory has been paged out. This may result in a performance degradation. Duration: #### seconds. Working set (KB): ####, committed (KB): ####, memory utilization: ##%.

Ändringar i minneshantering från och med SQL Server 2012

I äldre versioner av SQL Server gjordes minnesallokering med fem olika mekanismer:

  • Single-Page Allokerare (SPA) som omfattar enbart minnesallokeringar som var mindre än eller lika med 8 KB i SQL Server-processen. Konfigurationsalternativen för maximalt serverminne (MB) och minsta serverminne (MB) fastställde gränserna för det fysiska minne som SPA:et förbrukade. Buffertpoolen var samtidigt mekanismen för SPA och den största konsumenten av ensidesallokeringar.
  • Multi-Page Allocator (MPA), för minnesallokeringar som begär mer än 8 KB.
  • CLR-allokerare, inklusive SQL CLR-heaps och deras globala allokeringar som skapas under CLR-initialiseringen.
  • Minnesallokeringar för trådstackar i SQL Server-processen.
  • Direct Windows-allokeringar (DWA) för minnesallokeringsbegäranden som görs direkt till Windows. Dessa omfattar Användning av Windows-heap och direkta virtuella allokeringar som görs av moduler som läses in i SQL Server-processen. Exempel på sådana minnesallokeringsbegäranden är allokeringar från DLL:er för utökad lagrad procedur, objekt som skapas med hjälp av Automation-procedurer (sp_OA anrop) och allokeringar från länkade serverproviders.

Från och med SQL Server 2012 (11.x) konsolideras Single-Page allokeringar, allokeringar med flera sidor och CLR-allokeringar till en sidallokering av valfri storlek och ingår i minnesgränser som styrs av maximalt serverminne (MB) och minsta serverminne (MB). Den här ändringen gav en mer exakt storleksändring för alla minneskrav som går igenom SQL Server-minneshanteraren.

Viktigt!

Granska noggrant dina aktuella konfigurationer för maximalt serverminne (MB) och min serverminne (MB) när du har uppgraderat till SQL Server 2012 (11.x) och senare versioner. Det beror på att från och med SQL Server 2012 (11.x) inkluderar sådana konfigurationer nu och tar hänsyn till fler minnesallokeringar jämfört med tidigare versioner. Dessa ändringar gäller både 32-bitars- och 64-bitarsversioner av SQL Server 2012 (11.x) och SQL Server 2014 (12.x) och 64-bitars versioner av SQL Server 2016 (13.x) och senare versioner.

Följande tabell anger om en viss typ av minnesallokering styrs av konfigurationsalternativen för maximalt serverminne (MB) och minsta serverminne (MB ):

Typ av minnesallokering SQL Server 2005 (9.x), SQL Server 2008 (10.0.x) och SQL Server 2008 R2 (10.50.x) Börjar med SQL Server 2012 (11.x)
Allokeringar av enskilda sidor Ja Ja, konsolideras till sidallokeringar av valfri storlek
Allokeringar för flera sidor Nej Ja, konsolideras till sidallokeringar av valfri storlek
CLR-allokeringar Nej Ja
Trådstaplar minne Nej Nej
Direktallokeringar från Windows Nej Nej

SQL Server kan tilldela minne över angiven maxgräns för serverminne

Från och med SQL Server 2012 (11.x) kan SQL Server allokera mer minne än det värde som anges i inställningen för maximalt serverminne (MB). Det här beteendet kan inträffa när värdet för totalt serverminne (KB) redan har nått inställningen Målserverminne (KB), enligt vad som anges av maximalt serverminne (MB). Om det inte finns tillräckligt med sammanhängande ledigt minne för att möta efterfrågan på minnesbegäranden på flera sidor (mer än 8 KB) på grund av minnesfragmentering kan SQL Server utföra överåtagande i stället för att avvisa minnesbegäran.

Så snart den här allokeringen utförs börjar resursövervakarens bakgrundsaktivitet signalera alla minneskonsumenter att frigöra det allokerade minnet och försöker få värdet totalt serverminne (KB) under specifikationen målserverminne (KB). Sql Server-minnesanvändningen kan därför kort överskrida inställningen för maximalt serverminne (MB). I det här fallet överskrider prestandaräknaren för totalt serverminne (KB) inställningarna för maximalt serverminne (MB) och målserverminne (KB).

Det här beteendet observeras vanligtvis under följande åtgärder:

  • Stora columnstore-indexfrågor
  • Batchläge för stora rowstore-frågor
  • Återskapande av columnstore-index, vilka använder stora mängder minne för att utföra hash- och sorteringsoperationer
  • Säkerhetskopieringsåtgärder som kräver stora minnesbuffertar
  • Spårningsåtgärder som måste lagra stora indataparametrar
  • Begäranden om stora minnestilldelningar

Om du observerar det här beteendet ofta bör du överväga att använda spårningsflagga 8121 i SQL Server 2019 (15.x) för att göra det möjligt för Resursövervakaren att rensa snabbare. Från och med SQL Server 2022 (16.x) aktiveras den här funktionen som standard och spårningsflaggan har ingen effekt.

Ändringar i memory_to_reserve från och med SQL Server 2012

I äldre versioner av SQL Server reserverade SQL Server-minneshanteraren en del av processens virtuella adressutrymme (VAS) för användning av MPA (Multi-Page Allocator),CLR Allocator, minnesallokeringar för trådstackar i SQL Server-processen och Direct Windows-allokeringar (DWA). Den här delen av det virtuella adressutrymmet kallas även "Mem-To-Leave" eller "icke-Buffer Pool-området".

Det virtuella adressutrymme som är reserverat för dessa allokeringar bestäms av konfigurationsalternativet memory_to_reserve . Standardvärdet som SQL Server använder är 256 MB.

Eftersom sidallokeraren "valfri storlek" även hanterar allokeringar som är större än 8 kB, inkluderar memory_to_reserve-värdet inte allokeringar av flera sidor. Förutom den här ändringen förblir allt annat detsamma med det här konfigurationsalternativet.

Följande tabell anger om en specifik typ av minnesallokering hamnar i den memory_to_reserve regionen för det virtuella adressutrymmet för SQL Server-processen:

Typ av minnesallokering SQL Server 2005 (9.x), SQL Server 2008 (10.0.x) och SQL Server 2008 R2 (10.50.x) Börjar med SQL Server 2012 (11.x)
Allokeringar av enskilda sidor Nej Nej, konsolideras i sidallokeringar av "valfri storlek"
Allokeringar för flera sidor Ja Nej, konsolideras i sidallokeringar av "valfri storlek"
CLR-allokeringar Ja Ja
Trådstaplar minne Ja Ja
Direktallokeringar från Windows Ja Ja

Dynamisk minneshantering

Standardbeteendet för minneshantering för SQL Server Database Engine är att hämta så mycket minne som behövs utan att skapa minnesbrist i systemet. SQL Server Database Engine gör detta med hjälp av API:erna för minnesmeddelanden i Microsoft Windows.

När SQL Server använder minne dynamiskt frågar det systemet regelbundet för att fastställa mängden ledigt minne. Genom att behålla det här lediga minnet förhindrar du att operativsystemet (OS) använder sig av paginering. Om mindre minne är ledigt släpper SQL Server ut minne till operativsystemet. Om mer minne är ledigt kan SQL Server allokera mer minne. SQL Server lägger bara till minne när dess arbetsbelastning kräver mer minne. en vilande server ökar inte storleken på dess virtuella adressutrymme. Om du märker att Aktivitetshanteraren och Prestandaövervakaren visar en stadig minskning av tillgängligt minne när SQL Server använder dynamisk minneshantering är detta standardbeteendet och bör inte uppfattas som en minnesläcka.

Konfigurationsalternativ för serverminne styr SQL Server-minnesallokering, kompilering av minne, alla cacheminnen (inklusive buffertpoolen), minnestilldelning för frågekörning, låshanterarens minne och CLR1-minne (i princip alla minnesbiträden som finns i sys.dm_os_memory_clerks).

1 CLR-minne hanteras under max_server_memory allokeringar som börjar med SQL Server 2012 (11.x).

Följande fråga returnerar information om för närvarande allokerat minne:

SELECT physical_memory_in_use_kb / 1024 AS sql_physical_memory_in_use_MB,
       large_page_allocations_kb / 1024 AS sql_large_page_allocations_MB,
       locked_page_allocations_kb / 1024 AS sql_locked_page_allocations_MB,
       virtual_address_space_reserved_kb / 1024 AS sql_VAS_reserved_MB,
       virtual_address_space_committed_kb / 1024 AS sql_VAS_committed_MB,
       virtual_address_space_available_kb / 1024 AS sql_VAS_available_MB,
       page_fault_count AS sql_page_fault_count,
       memory_utilization_percentage AS sql_memory_utilization_percentage,
       process_physical_memory_low AS sql_process_physical_memory_low,
       process_virtual_memory_low AS sql_process_virtual_memory_low
FROM sys.dm_os_process_memory;

Stackstorlekar

Minne för trådstackar 1, CLR 2, utökad procedur .dll filer, OLE DB-providers som refereras av distribuerade frågor, automationsobjekt som refereras i Transact-SQL-instruktioner och allt minne som allokeras av en icke SQL Server DLL, styrs inte av maximalt serverminne (MB).

1 Konsultera artikeln om hur du kan konfigurera maximalt antal arbetstrådar (serverkonfigurationsalternativ) för information om de beräknade standardarbetstrådarna för ett givet antal CPU:er tilldelade i den aktuella värdmiljön. SQL Server-stackstorlekar är följande:

SQL Server-arkitektur OS-arkitektur Stackstorlek
x86 (32-bitars) x86 (32-bitars) 512 kB
x86 (32-bitars) x64 (64-bitars) 768 KB
x64 (64-bitars) x64 (64-bitars) 2 048 KB
IA64 (Itanium) IA64 (Itanium) 4 096 KB

2 CLR-minne hanteras under max_server_memory allokeringar som börjar med SQL Server 2012 (11.x).

SQL Server använder minnesmeddelandet API QueryMemoryResourceNotification för att avgöra när SQL Server-minneshanteraren kan allokera minne och frigöra minne.

När SQL Server startar beräknas storleken på det virtuella adressutrymmet för buffertpoolen baserat på flera parametrar, till exempel mängden fysiskt minne i systemet, antalet servertrådar och olika startparametrar. SQL Server reserverar den beräknade mängden av sitt processens virtuella adressutrymme för buffertpoolen, men den allokerar endast den nödvändiga mängden fysiskt minne för den aktuella belastningen.

Instansen fortsätter sedan att allocera minne efter behov för att stötta arbetsbelastningen. När fler användare ansluter och kör frågor hämtar SQL Server mer fysiskt minne på begäran. En SQL Server-instans fortsätter att hämta fysiskt minne tills den når sitt maximala mål för serverminnesallokering (MB) eller operativsystemet anger att det inte längre finns ett överskott av ledigt minne. det frigör minne när det är mer än inställningen minsta serverminne, och operativsystemet anger att det finns brist på ledigt minne.

När andra program startas på en dator som kör en instans av SQL Server förbrukar de minne och mängden ledigt fysiskt minne sjunker under SQL Server-målet. Sql Server-instansen justerar minnesförbrukningen. Om ett annat program stoppas och mer minne blir tillgängligt ökar instansen av SQL Server storleken på dess minnesallokering. SQL Server kan frigöra och hämta flera megabyte minne varje sekund, så att det snabbt kan justeras till ändringar i minnesallokering.

Effekter av minimalt och maximalt serverminne

Konfigurationsalternativen minsta serverminne och maxserverminne upprättar övre och nedre gränser för mängden minne som används av buffertpoolen och andra cacheminnen i databasmotorn. Buffertpoolen hämtar inte omedelbart mängden minne som anges i det minimala serverminnet. Buffertpoolen börjar med endast det minne som krävs för att initiera. När SQL Server Database Engine-arbetsbelastningen ökar hämtar den hela tiden det minne som krävs för att stödja arbetsbelastningen. Buffertpoolen frigör inte något av det förvärvade minnet förrän den når den mängd som anges i minsta serverminne. När minsta serverminne har uppnåtts använder buffertpoolen sedan standardalgoritmen för att hämta och frigöra minne efter behov. Den enda skillnaden är att buffertpoolen aldrig släpper sin minnesallokering under den nivå som anges i minsta serverminne och aldrig hämtar mer minne än den nivå som anges i max serverminne (MB).

Anmärkning

SQL Server som en process hämtar mer minne än vad som anges av alternativet för maximalt serverminne (MB). Både interna och externa komponenter kan allokera minne utanför buffertpoolen, vilket förbrukar ytterligare minne, men det minne som allokeras till buffertpoolen representerar vanligtvis fortfarande den största delen av minnet som förbrukas av SQL Server.

Mängden minne som hämtas av SQL Server Database Engine är helt beroende av den arbetsbelastning som placeras på instansen. En SQL Server-instans som inte bearbetar många begäranden kanske aldrig når det värde som anges av min serverminne.

Om samma värde anges för både min serverminne och maximalt serverminne (MB) slutar SQL Server Database Engine att dynamiskt frigöra och hämta minne för buffertpoolen när minnet som allokerats till SQL Server Database Engine når det värdet.

Om en instans av SQL Server körs på en dator där andra program ofta stoppas eller startas, kan allokeringen och frigöring av minne av SQL Server-instansen sakta ned starttiderna för andra program. Om SQL Server är ett av flera serverprogram som körs på en enda dator bör systemadministratörerna också styra mängden minne som allokeras till SQL Server. I dessa fall kan du använda alternativen minsta serverminne och maximalt serverminne (MB) för att styra hur mycket minne SQL Server kan använda. Alternativen minsta serverminne och maximalt serverminne anges i megabyte. Mer information, inklusive rekommendationer om hur du ställer in dessa minneskonfigurationer, finns i Konfigurationsalternativ för serverminne.

Minne som används av SQL Server-objektspecifikationer

I följande lista beskrivs den ungefärliga mängden minne som används av olika objekt i SQL Server. De angivna beloppen är uppskattningar och kan variera beroende på miljö och hur objekt skapas:

  • Lås (enligt låshanteraren): 64 byte + 32 byte per ägare
  • Användaranslutning: Ungefär (3 * network_packet_size + 94 KB)

Storleken på nätverkspaketen är storleken på TDS-paketen (Tabular Data Stream) som används för att kommunicera mellan program och databasmotorn. Standardpaketstorleken är 4 kB och styrs av konfigurationsalternativet för nätverkspaketstorlek.

När flera aktiva resultatuppsättningar (MARS) är aktiverade är användaranslutningen ungefär (3 + 3 * num_logical_connections) * network_packet_size + 94 KB.

Effekter av minsta minne per fråga

Konfigurationsalternativet minsta minne per fråga anger den minsta mängd minne (i kilobyte) som ska allokeras för körningen av en fråga. Detta kallas även för det minsta minnesbidraget. Alla frågor måste vänta tills det minsta begärda minnet kan skyddas, innan körningen kan starta eller tills värdet som anges i konfigurationsalternativet för frågevänteservern har överskridits. Den väntetyp som ackumuleras i det här scenariot är RESOURCE_SEMAPHORE.

Viktigt!

Ställ inte in konfigurationsalternativet minsta minne per frågeserver för högt, särskilt inte på mycket upptagna system, eftersom det kan leda till:

  • Ökad konkurrens om minnesresurser.
  • Minskad samtidighet genom att öka mängden minne för varje enskild fråga, även om det minne som krävs vid körning är lägre än den här konfigurationen.

Rekommendationer om hur du använder den här konfigurationen finns i Konfigurera serverkonfigurationsalternativet minsta minne per fråga.

Överväganden för minnesbidrag

För körning av radläge kan det första minnesbidraget inte överskridas under något villkor. Om mer minne än det initiala beviljandet behövs för att köra hash- eller sorteringsåtgärder spiller åtgärderna till disken. En hash-åtgärd som spiller stöds av en Workfile i tempdb, medan en sorteringsåtgärd som spiller stöds av en Worktable.

Ett spill som inträffar under en sorteringsåtgärd kallas för en händelseklass för sorteringsvarningar. Sorteringsvarningar anger att sorteringsåtgärder inte får plats i minnet. Detta inkluderar inte sorteringsåtgärder som omfattar skapande av index, endast sorteringsåtgärder i en fråga (till exempel en ORDER BY sats som används i en SELECT -instruktion).

Ett spill som inträffar under en hash-åtgärd kallas hashvarningshändelseklass. Dessa inträffar när en hash-rekursion eller upphörande av hash-operationen har inträffat under en hash-operation.

  • Hash-rekursion inträffar när byggindata inte passar in i tillgängligt minne, vilket resulterar i delning av indata i flera partitioner som bearbetas separat. Om någon av dessa partitioner fortfarande inte passar in i tillgängligt minne delas den upp i underpartitioner, som också bearbetas separat. Den här delningsprocessen fortsätter tills varje partition passar in i tillgängligt minne eller tills den maximala rekursionsnivån har nåtts.
  • Hash-räddningsaktion sker när en hash-åtgärd når sin maximala rekursionsnivå och övergår till en alternativ plan för att bearbeta återstående partitionerade data. Dessa händelser kan orsaka lägre prestanda på servern.

Vid körning av batchläge kan det första minnestillslaget dynamiskt öka upp till ett visst internt tröskelvärde som standard. Den här mekanismen för dynamisk minnesbeviljning är utformad för att tillåta minnesresiderande körning av hash- eller sortering som körs i batchläge. Om dessa åtgärder fortfarande inte får plats i minnet, kommer de att överföras till disken.

Mer information om körningslägen finns i arkitekturguiden för frågebearbetning.

Bufferthantering

Det primära syftet med en SQL Server-databas är att lagra och hämta data, så intensiv disk-I/O är en grundläggande egenskap hos databasmotorn. Och eftersom disk-I/O-åtgärder kan förbruka många resurser och ta relativt lång tid att slutföra, fokuserar SQL Server på att göra I/O mycket effektivt. Bufferthantering är en viktig komponent för att uppnå den här effektiviteten. Bufferthanteringskomponenten består av två mekanismer: bufferthanteraren för åtkomst till och uppdatering av databassidor och buffertcachen (kallas även buffertpoolen) för att minska databasfilens I/O.

En detaljerad förklaring av disk-I/O i SQL Server finns i grunderna för SQL Server I/O.

Så här fungerar bufferthantering

En buffert är en 8 KB-sida i minnet, samma storlek som en data- eller indexsida. Buffertcachen är därför indelad i 8 KB-sidor. Bufferthanteraren hanterar funktionerna för att läsa data eller indexsidor från databasdiskfilerna till buffertcachen och skriva ändrade sidor tillbaka till disken. En sida finns kvar i buffertcachen tills bufferthanteraren behöver buffertområdet för att läsa in mer data. Data skrivs tillbaka till disken endast om det har ändrats. Data i buffertcachen kan ändras flera gånger innan de skrivs tillbaka till disken. Mer information finns i Läsa sidor och Skriva sidor.

När SQL Server startar beräknas storleken på det virtuella adressutrymmet för buffertcachen baserat på flera parametrar, till exempel mängden fysiskt minne i systemet, det konfigurerade antalet maximala servertrådar och olika startparametrar. SQL Server reserverar denna beräknade mängd av sitt processens virtuella adressutrymme, som kallas minnesmålet, för buffertcachen, men den allokerar endast den nödvändiga mängden fysiskt minne för den nuvarande belastningen. Du kan ställa frågor på kolumnerna committed_target_kb och committed_kb i sys.dm_os_sys_info katalogvyn för att returnera antalet sidor som reserverats som minnesmängd respektive antalet sidor som för närvarande har allokerats i buffertcachen.

Intervallet mellan SQL Server-start och när buffertcachen hämtar sitt minnesmål kallas ramp-up. Under den här tiden fyller läsbegäranden buffertarna efter behov. Till exempel fyller en enda 8 KB-sidläsningsbegäran en enda buffertsida. Det innebär att rampen beror på antalet och typen av klientbegäranden. Upprampningen påskyndas genom att enstaka sidläsningsbegäranden omvandlas till justerade åtta sidbegäranden (vilket utgör en omfattning). Detta gör att uppstarten slutförs mycket snabbare, särskilt på datorer med mycket minne. Mer information om sidor och omfattningar finns i Arkitekturguide för sidor och omfattningar.

Eftersom bufferthanteraren använder det mesta av minnet i SQL Server-processen samarbetar den med minneshanteraren för att tillåta att andra komponenter använder sina buffertar. Bufferthanteraren interagerar främst med följande komponenter:

  • Resource Manager för att styra den totala minnesanvändningen och, på 32-bitarsplattformar, för att kontrollera adressutrymmets användning.
  • Database Manager och SQL Server Operating System (SQLOS) för fil-I/O-åtgärder på låg nivå.
  • Log Manager för förskrivningsloggning.

Funktioner som stöds

Bufferthanteraren stöder följande funktioner:

  • Bufferhanteraren är NUMA-medveten (non-uniform memory access). Buffertcachesidor distribueras över maskinvaru-NUMA-noder, vilket gör att en tråd kan komma åt en buffertsida som allokeras på den lokala NUMA-noden i stället för från främmande minne.

  • Buffert-hanteraren stöder Hot Add Memory, vilket gör att användare kan lägga till fysiskt minne utan att starta om servern.

  • Bufferthanteraren stöder stora sidor på 64-bitarsplattformar. Sidstorleken är specifik för windowsversionen.

    Anmärkning

    Innan SQL Server 2012 (11.x) krävs spårningsflagga 834 för att aktivera stora sidor i SQL Server.

  • Bufferthanteraren tillhandahåller extra diagnostik som exponeras via dynamiska hanteringsvyer. Du kan använda dessa vyer för att övervaka olika operativsystemresurser som är specifika för SQL Server. Du kan till exempel använda vyn sys.dm_os_buffer_descriptors för att övervaka sidorna i buffertcachen.

Minnestrycksdetektering

Minnestryck är ett villkor som beror på minnesbrist och kan resultera i:

  • Extra I/Os (till exempel en mycket aktiv bakgrundstråd för lat författare)
  • Högre omkompileringsförhållande
  • Längre frågeställningar (om det finns väntetider för tilldelning av minne)
  • Extra CPU-cykler

Den här situationen kan utlösas av externa eller interna orsaker. Externa orsaker är:

  • Tillgängligt fysiskt minne (RAM) är lågt. Detta gör att systemet trimmar arbetsuppsättningar för processer som körs för närvarande, vilket kan leda till en total avmattning. SQL Server kan minska incheckningsmålet för buffertpoolen och börja trimma interna cacheminnen oftare.
  • Det övergripande tillgängliga systemminnet (som innehåller systemsidefilen) är lågt. Detta kan göra att systemet misslyckas med minnesallokeringar, eftersom det inte kan ta bort allokerat minne.

Interna orsaker är:

  • När SQL Server Database Engine sätter en lägre gräns för minnesanvändning som svar på det externa minnesanvändningstrycket.
  • Minnesinställningarna sänktes manuellt genom att minska den maximala serverminneskonfigurationen .
  • Ändringar i minnesfördelningen av interna komponenter mellan flera cacheminnen.

SQL Server Database Engine implementerar ett ramverk som är dedikerat för att identifiera och hantera minnestryck som en del av dess dynamiska minneshantering. Det här ramverket innehåller bakgrundsaktiviteten Resource Monitor. Resursövervakaren övervakar tillståndet för externa och interna minnesindikatorer. När någon av dessa indikatorer ändrar status beräknar den motsvarande meddelande och sänder det. Dessa meddelanden är interna meddelanden från var och en av motorkomponenterna och lagras i ringbuffertar.

Två ringbuffertar innehåller information som är relevant för dynamisk minneshantering:

  • Resursövervakarens ringbuffert, som spårar aktivitet såsom om minnesbelastning signalerades eller inte. Den här ringbufferten har statusinformation beroende på det aktuella villkoret för RESOURCE_MEMPHYSICAL_HIGH, RESOURCE_MEMPHYSICAL_LOW, RESOURCE_MEMPHYSICAL_STEADY, eller RESOURCE_MEMVIRTUAL_LOW.
  • Memory Broker-ringbufferten, som innehåller poster med minnesmeddelanden för varje resurspool i Resource Governor. När internt minnestryck identifieras aktiveras meddelanden om lågt minne för komponenter som allokerar minne för att utlösa åtgärder som är avsedda att balansera minnet mellan cacheminnen.

Minneskoordinatorer övervakar minnesförbrukningen för varje komponent och beräknar och optimalt minnesvärde för var och en av dessa komponenter baserat på den information som samlas in. Det finns en uppsättning mäklare för varje resurspool i Resource Governor. Den här informationen sänds sedan till var och en av komponenterna, som ökar eller minskar deras användning efter behov.

Mer information om minneskoordinatorer finns i sys.dm_os_memory_brokers.

Feldetektering

Databassidor kan använda någon av två valfria mekanismer som hjälper till att säkerställa sidans integritet, från den tidpunkt då den skrivs till disk, tills den läss igen: slitet sidskydd och kontrollsummaskydd. De här mekanismerna möjliggör en oberoende metod för att verifiera korrektheten hos inte bara datalagringen, utan även maskinvarukomponenter som styrenheter, drivrutiner, kablar och till och med operativsystemet. Skyddet läggs till på sidan precis innan det skrivs till disken och verifieras när det har lästs från disken.

SQL Server försöker läsa igen som misslyckas med en kontrollsumma, en sönderriven sida eller ett annat I/O-fel fyra gånger. Om läsningen lyckas i något av återförsöken skrivs ett meddelande till felloggen och kommandot som utlöste läsningen fortsätter. Om återförsöken misslyckas misslyckas kommandot med felet MSSQLSERVER_824 .

Den typ av sidskydd som används är ett attribut för databasen som innehåller sidan. Kontrollsummaskydd är standardskyddet för databaser som skapats i SQL Server 2005 (9.x) och senare versioner. Sidskyddsmekanismen anges när databasen skapas och kan ändras med hjälp ALTER DATABASE SETav . Du kan fastställa den aktuella sidas skyddsinställning genom att fråga kolumnen page_verify_option i katalogvyn sys.databases eller egenskapen IsTornPageDetectionEnabled för funktionen DATABASEPROPERTYEX.

Anmärkning

Om sidskyddsinställningen ändras påverkar den nya inställningen inte omedelbart hela databasen. I stället använder sidorna databasens aktuella skyddsnivå när de skrivs härnäst. Det innebär att databasen kan bestå av sidor med olika typer av skydd.

Slitet sidskydd

Det sönderrivna sidskyddet, som introducerades i SQL Server 2000 (8.x), är främst ett sätt att identifiera sidfel på grund av strömavbrott. Ett oväntat strömavbrott kan till exempel bara lämna en del av en sida skriven till disken. När slitet sidskydd används, skapas ett specifikt 2-bitars signaturmönster för varje 512-byte sektor på 8-kilobytesdatabassidan, och detta lagras i databassidans sidhuvud när sidan skrivs till disk.

När sidan läss från disk jämförs de sönderrivna bitarna som lagras i sidhuvudet med den faktiska sidsektorinformationen. Signaturmönstret växlar mellan binärt 01 och 10 med varje skrivning, så det är alltid möjligt att se när endast en del av sektorerna kom till disken: om en bit är i fel tillstånd när sidan senare läss, skrevs sidan felaktigt och en sönderriven sida identifieras. Identifiering av slitna sidor använder minimala resurser. Den identifierar dock inte alla fel som orsakas av diskmaskinvarufel. Information om hur du ställer in identifiering av skadade sidor finns i ALTER DATABASE SET Options (Transact-SQL).

Kontrollsummaskydd

Kontrollsummaskydd, som introducerades i SQL Server 2005 (9.x), ger starkare dataintegritetskontroll. En kontrollsumma beräknas för data på varje sida som skrivs och lagras i sidhuvudet. När en sida med en lagrad kontrollsumma läss från disk beräknar databasmotorn om kontrollsumman för data på sidan och genererar fel 824 om den nya kontrollsumman skiljer sig från den lagrade kontrollsumman. Kontrollsummaskyddet kan fånga upp fler fel än skyddet mot sönderrivna sidor eftersom varje byte av sidan påverkar det, men det är måttligt resursintensivt.

När kontrollsumman är aktiverad kan fel som orsakas av strömavbrott och felaktig maskinvara eller inbyggd programvara identifieras när bufferthanteraren läser en sida från disken. Information om hur du ställer in kontrollsumma finns i ALTER DATABASE SET Options (Transact-SQL).

Viktigt!

När en användare eller systemdatabas uppgraderas till SQL Server 2005 (9.x) eller senare behålls det PAGE_VERIFY värdet (NONE eller TORN_PAGE_DETECTION). Vi rekommenderar starkt att du använder CHECKSUM. TORN_PAGE_DETECTION kan använda färre resurser, men ger en minimal delmängd av CHECKSUM skyddet.

Förstå icke-enhetlig minnesåtkomst

SQL Server är medveten om icke-enhetlig minnesåtkomst (NUMA) och fungerar bra på NUMA-maskinvara utan särskild konfiguration. När klockhastigheten och antalet processorer ökar blir det allt svårare att minska den minnesfördröjning som krävs för att använda den här extra bearbetningskraften. För att kringgå detta tillhandahåller maskinvaruleverantörer stora L3-cacheminnen, men detta är bara en begränsad lösning. NUMA-arkitekturen ger en skalbar lösning på det här problemet.

SQL Server är utformat för att dra nytta av NUMA-baserade datorer utan att kräva några programändringar. Mer information finns iSoft-NUMA (SQL Server).

Dynamisk partition av minnesobjekt

Heap-allokerare, så kallade minnesobjekt i SQL Server, gör det möjligt för databasmotorn att allokera minne från heapen. Dessa kan spåras med hjälp av sys.dm_os_memory_objects DMV.

CMemThread är en trådsäker minnesobjekttyp som tillåter samtidiga minnesallokeringar från flera trådar. För korrekt spårning CMemThread förlitar sig objekt på synkroniseringskonstruktioner (en mutex) för att säkerställa att endast en enda tråd uppdaterar viktig information i taget.

Anmärkning

Objekttypen CMemThread används i hela databasmotorns kodbas för många olika allokeringar och kan partitioneras globalt, per nod eller cpu.

Användningen av mutex kan dock leda till konkurrens om många trådar allokeras från samma minnesobjekt på ett mycket samtidigt sätt. Därför har SQL Server begreppet partitionerade minnesobjekt (PMO) och varje partition representeras av ett enda CMemThread objekt. Partitioneringen av ett minnesobjekt är statiskt definierad och kan inte ändras när det har skapats. Eftersom minnesallokeringsmönstren varierar mycket beroende på aspekter som maskinvaru- och minnesanvändning är det omöjligt att komma med det perfekta partitioneringsmönstret direkt.

I de flesta fall räcker det att använda en enda partition, men i vissa scenarier kan detta leda till konkurrens, vilket endast kan förhindras med ett minnesobjekt med hög partitionering. Det är inte önskvärt att partitionera varje minnesobjekt eftersom fler partitioner kan resultera i andra ineffektiviteter och öka minnesfragmenteringen.

Anmärkning

Innan SQL Server 2016 (13.x) kan spårningsflagga 8048 användas för att tvinga en nodbaserad PMO att bli en CPU-baserad PMO. Från och med SQL Server 2014 (12.x) SP2 och SQL Server 2016 (13.x) är det här beteendet dynamiskt och styrt av motorn.

Från och med SQL Server 2014 (12.x) SP2 och SQL Server 2016 (13.x) kan databasmotorn dynamiskt identifiera konkurrens på ett specifikt CMemThread objekt och höja upp objektet till en per nod eller en per CPU-baserad implementering. När den har befordrats förblir PMO uppflyttad tills SQL Server-processen startas om. CMemThread konkurrens kan identifieras av förekomsten av höga CMEMTHREAD väntetider i sys.dm_os_wait_stats DMV och genom att observera sys.dm_os_memory_objects DMV-kolumner contention_factor, partition_type, exclusive_allocations_countoch waiting_tasks_count.

Relaterat innehåll