SQLServer: Buffer Cache Hit ratio is een goede indicatie van MOGELIJK geheugenknelpunt?

Ik ben op zoek naar een indicatie (indien aanwezig) die ofwel de geheugenknelpuntoptie negeert, ofwel accepteert, of me dwingt verder te onderzoeken.

bijvoorbeeld:

levensverwachting van pagina:

SELECT [object_name], [counter_name], [cntr_value] FROM sys.dm_os_performance_counters WHERE [object_name] LIKE "%Manager%" AND [counter_name] = "Page life expectancy" 

voer de beschrijving van de afbeelding hier in

Bij deze gelegenheid heb ik in mijn huidige omgeving een server met 8 GB RAM, ik zou het management willen vragen voor meer geheugen. Ik denk dat dit een geheugenknelpunt is.

wat het RAM-geheugen gebruikt, zou een ander onderzoek zijn.

is deze e-mail hieronder geldig om mogelijke geheugenknelpunten te identificeren?

we moeten kijken naar SQLServer: Buffer Cache Hit ratio

Als die ratio minder is dan 95% dan staat de server onder geheugendruk

Ik hoop dat dit helpt,

voer hier een afbeeldingsbeschrijving in

Opmerkingen

  • Baseer uw suggestie over geheugen niet op Buffer Cache hit ratio . Lees Geweldig SQL Server-debat over BCHR als feit dat ik nooit op deze teller vertrouw. U kunt op PLE vertrouwen, maar u moet PLE zien voor alle NUMA-knooppunten (als u die heeft).
  • De PLE-waarde lijkt erg laag te zijn, maar andere tellers zijn prima. Je hebt de vraag getagd met twee versies, ik kan je een lijst met tellers geven om het geheugengebruik te controleren, maar aangezien er twee versies bij betrokken zijn, is er een klein verschil. Naar welke versie kijk je precies

Antwoord

We moeten kijken naar SQLServer: Buffer Cache Hit ratio. Als die ratio minder is dan 95% dan staat de server onder geheugendruk

Stop met kijken naar Buffer Cache-hit-ratio om de geheugendruk te bepalen. Dit komt doordat met vooruitleesmechanisme in SQL Server meer dan voldoende paginas al in de bufferpool aanwezig zijn om aan de vraag te voldoen, zodat BCHR geen nauwkeurig cijfer geeft over de geheugendruk. Je zou zelfs kunnen zien dat BCHR zelfs niet zou dalen als er geheugendruk is. Dit alles is uitgelegd in Geweldig SQL Server-debat over BCHR

PLE-uitvoer die je hebt gepost lijkt erg laag, maar we kunnen niet slechts één teller gebruiken om meet geheugen druk. PLE is meer een indicatie van I / O-activiteit op de server. Het is mogelijk dat PLE als gevolg van zware I / O-activiteit kelderde. Als u opmerkt dat het doel- en totale servergeheugen nog steeds hetzelfde blijft. Dat is een goed teken.

Voor Edition upto 2008 R2. U kunt onderstaande tellers gebruiken

  1. SQLServer: Buffer Manager – CheckpointPages / sec:

  2. SQLServer: Buffer Manager – Memory Grants In afwachting van:

  3. SQLServer: Buffer Manager – Doelservergeheugen:

  4. SQLServer: Buffer Manager – Totaal servergeheugen

  5. SQLServer: Buffer Manager – Gratis paginas

  6. SQLServer: Buffer Manager – Free List Stall / sec

  7. SQLServer: Buffer Manager – Levensverwachting van pagina

Voor SQL Server 2012 onwards enkele van Buffer Pooltellers zijn verouderd en daarom moeten we Memory Manager-tellers gebruiken

  1. SQL Server: Memory Manager– Target Server Memory (KB)

  2. SQL Server: geheugenbeheer – totaal servergeheugen (KB)

  3. SQL Server: geheugenbeheerder – vrij geheugen (KB)

  4. SQL Server: geheugenbeheer – databasecachegeheugen (KB)

  5. SQLServer: bufferbeheer – gratis paginas

  6. SQLServer: Buffer Manager – Free List Stall / sec

  7. SQLServer: Buffer Manager – Levensverwachting van pagina

Merk op dat als u zware schijfactiviteit heeft, vergeet niet om ook schijfgerelateerde tellers te raadplegen. Maak een gegevensverzamelaarset en laat deze 4-5 uur draaien als de belasting van het systeem piekt, en voeg vervolgens de momentopname van de gegevensverzamelaar toe aan uw vraag. Vervolgens kunnen we bepalen of SQL Server meer geheugen nodig heeft of niet.

Persoonlijk is 8G iets minder RAM gezien de huidige werkbelasting en OS-vereisten. Denk er altijd aan om RAM te vergroten.

Antwoord

we moeten kijken naar SQLServer: Buffer Cache Hit ratio

Als die ratio minder is dan 95% dan staat de server onder geheugendruk

Ik hoop dat dit helpt,

Dit is niet wat je zeker zal helpen bij het bepalen van het geheugenknelpunt op zichzelf. Wat ik liever zou hebben, is om de gegevens voor onderstaande tellers minstens een dag tijdens de zware belasting / kantooruren te verzamelen.

Memory – Available MBytes SQLServer: Buffer Manager – Page Life Expectancy SQLServer: Memory Manager – Memory Grants Pending SQLServer: Memory Manager – Target Server Memory SQLServer: Memory Manager – Total Server Memory SQLServer: SQL Statistics – Batch Requests/sec SQLServer: SQL Statistics – Compilations/sec 

Het beste zou de basislijn van de SQL-server zijn, zoals voorgesteld Terug naar de basis: basislijnen vastleggen op productie-SQL Servers die ook de vereiste perfmon-tellers verzamelen, samen met wachtstatistieken voor elk probleem.

Ook 8 GB RAM is misschien niet zo geschikt als de huidige omgeving, maar nogmaals, het hangt ervan af wat is de belasting van het systeem samen met de grootte van de databases die worden gehost op de instance \ instances.

Geef een reactie

Het e-mailadres wordt niet gepubliceerd. Vereiste velden zijn gemarkeerd met *