Buffercache:wat is het en hoe beïnvloedt het de databaseprestaties?

In SQL Server is de buffercache het geheugen waarmee u snel veelgebruikte gegevens kunt opvragen. Wanneer gegevens worden geschreven naar of gelezen uit een SQL Server-database, kopieert de buffermanager deze naar de buffercache (ook wel de bufferpool genoemd). Als deze vol is, worden oudere of minder vaak gebruikte gegevenspagina's naar de harde schijf verplaatst.

Waarom moet ik de buffercache bewaken?

Geheugengebruik kan een aanzienlijke invloed hebben op de prestaties. Als er onvoldoende geheugen is, worden gegevenspagina's regelmatig uit de buffercache verwijderd. Dit vertraagt ​​query's omdat SQL Server naar de schijf moet gaan om de gegevenspagina te vinden, deze moet herstellen naar de buffercache en vervolgens de pagina moet lezen voordat deze queryresultaten kan retourneren.

Er zijn veel redenen waarom query's langzaam beginnen te lopen. Maar als u geheugenproblemen wilt uitsluiten, kijk dan wat er in de buffercache gebeurt. Als je erin kijkt, kun je zien welke database, tabel of index het geheugen in beslag neemt en de buffer onder druk zet.

Gebruik de volgende query om te zien welke database het meeste geheugen verbruikt:

SELECTCASE database_idWHEN 32767 THEN 'ResourceDb'ELSE db_name(database_id)END AS database_name, COUNT(1)/128 AS megabytes_in_cacheFROM sys.dm_os_buffer_descriptorsGROUP BY DB_NAME(database_id), database_idORDER BY megabytes_in_cache> 

 Om de tabel of index te identificeren die het meeste geheugen verbruikt, voert u deze query uit in de database die u wilt inspecteren:
 
SELECT COUNT(1)/128 AS megabytes_in_cache,name,index_idFROM sys.dm_os_buffer_descriptors AS bdINNER JOIN(SELECT object_name(object_id) AS name,index_id,allocation_unit_idFROM sys.allocation_units AS auINNER JOIN sys.partitions AS pids.partitions AS .hobt_idAND (au.type =1 OR au.type =3) UNION ALLSELECT objectnaam (object_id) AS naam, index_id, allocatie_eenheid_idFROM sys.allocation_units AS auINNER JOIN sys.partitions AS pON au.container_id =p.partition_idAND au.type =2 ) AS objON bd.allocation_unit_id =obj.allocation_unit_idWHERE database_id =DB_ID()GROUP BY naam, index_idORDER BY megabytes_in_cache DESC;
 
Geheugen beheren met statistieken
 

 Hoewel het handig is om databases en indexen te controleren op overmatig gebruik van geheugen, is het bijhouden van buffercachestatistieken echt de beste manier om prestatieproblemen te identificeren en op te lossen die worden veroorzaakt door interne druk op het geheugen.
 

 Hier zijn de vijf belangrijkste statistieken die u moet controleren om geheugengerelateerde prestatieproblemen te verbeteren:
 
1. Buffer Cache Hit Ratio
 
 
Deze statistiek laat zien hoe SQL Server buffercache gebruikt
 
De hitratio identificeert het percentage paginaverzoeken dat is voltooid door gegevenspagina's uit de buffercache versus alle gegevenspaginaverzoeken
 
Pagina's die niet in de buffercache worden gevonden, worden van de schijf gelezen, wat veel langzamer is
 
De ideale buffercacheverhouding is 100 (d.w.z. SQL Server leest alle pagina's uit de buffercache en geen enkele van de schijf)
 
De aanbevolen buffercachewaarde is groter dan 90
 
 
2. Paginalevensverwachting (PLE)
 
 
De levensverwachting van pagina's meet hoe lang (in seconden) een gegevenspagina in de buffercache blijft
 
Hoe langer de PLE, hoe groter de kans dat SQL Server de pagina's uit de buffercache leest en niet naar de schijf hoeft
 
Als er niet genoeg geheugen is, worden gegevenspagina's vaker uit de buffercache gewist om ruimte vrij te maken voor nieuwe pagina's
 
In het verleden, toen systemen veel minder geheugen hadden dan nu, was een "normale" PLE-waarde 300 seconden
 
Vandaag de dag wordt een formule gebruikt om de "goede" PLE te bepalen:Levensverwachting van pagina =300 seconden voor elke 4 GB RAM op uw server
 
De PLE moet stabiel blijven als deze in de loop van de tijd wordt gecontroleerd
 
Snelle, frequente afnames duiden op geheugenproblemen
 
Een daling van meer dan 50% moet onmiddellijk worden onderzocht
 
 
3. Paginalezingen/sec (serverniveau)
 
 
Deze statistiek laat zien hoeveel fysieke leesbewerkingen (d.w.z. leesbewerkingen vanaf schijf) in één seconde plaatsvonden in alle databases op een instantie
 
Fysiek lezen is duur en traag
 
Verminder fysieke leesbewerkingen door een grotere gegevenscache, intelligente indexen en efficiëntere zoekopdrachten te gebruiken, of door het databaseontwerp te wijzigen
 
De aanbevolen waarde is minder dan 90
 
Een waarde hoger dan 90 duidt op onvoldoende geheugen en problemen met indexeren
 
 
4. Pagina schrijft/sec
 
 
Deze statistiek toont het aantal keren dat pagina's in één seconde naar schijf zijn geschreven op serverniveau
 
De aanbevolen waarde is minder dan 90
 
 
5. Pagina's invoer/sec en pagina's uitvoer/sec (geheugentellers)
 
 
Pagina invoer/sec is het aantal pagina's dat elke seconde van de schijf wordt binnengebracht
 
Pages output/sec is het aantal pagina's dat elke seconde naar de schijf wordt geschreven om ruimte te maken in de buffercache
 
Pagina's/sec is de som van pagina's invoer/sec en pagina's uitvoer/sec
 
Als de pagina's/sec-waarde consequent meer dan 50 is, is aanvullend onderzoek nodig
 
 

 Een gezonde buffercache is een belangrijk onderdeel bij het optimaliseren van de querysnelheid van SQL Server. Hoewel geheugenproblemen slechts een van de vele factoren zijn die de respons op vragen kunnen vertragen, zijn ze vrij eenvoudig te identificeren en op te lossen. Door deze vijf belangrijke statistieken bij te houden, kunt u gegevenspagina's langer in de bufferpool houden, zodat SQL Server geen tijd hoeft te verspillen aan het doorzoeken van de schijf voordat de queryresultaten worden geretourneerd.