SQLServer: Buffercache Hit-forhold er en god indikation af MULIG hukommelsesflaskehals?

Jeg leder efter en eventuel indikation, der enten vil se bort fra hukommelsesflaskehalsmuligheden eller acceptere den eller få mig til at undersøge nærmere.

for eksempel:

forventet levetid på siden:

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

indtast billedebeskrivelse her

I denne lejlighed har jeg i mit nuværende miljø en server, der har 8 GB RAM, vil jeg bede ledelsen for mere hukommelse. Jeg tror, dette er en hukommelsesflaskehals.

hvad der bruger RAM, ville være en anden undersøgelse.

er denne e-mail nedenfor gyldig for at identificere mulige hukommelsesflaskehalse?

vi skal se på SQLServer: Buffercache-hitforhold

Hvis dette forhold er mindre end 95%, end serveren er under hukommelsestryk

Håber dette hjælper,

indtast billedebeskrivelse her

Kommentarer

  • Brug ikke dit forslag om hukommelse til at basere dig på Buffer Cache hit ratio . Læs Stor SQL Server-debat om BCHR , da jeg aldrig stoler på denne tæller. Du kan stole på PLE, men du skal se PLE for alle NUMA-noder (hvis du har)
  • PLE-værdien ser ud til at være meget mindre, men andre tællere er fine. Du mærkede spørgsmål med to versioner, jeg kan give dig en liste over tællere til overvågning af hukommelsesforbrug, men da der er to versioner involveret, er det lidt forskel. Hvilken version ser du nøjagtigt på

Svar

Vi er nødt til at se på SQLServer: Buffer Cache Hit-forhold. Hvis dette forhold er mindre end 95%, end serveren er under hukommelsestryk

Stop med at se på buffer Cache-hitforhold for at bestemme hukommelsestrykket. Dette skyldes, at med læs videre mekanisme i SQL Server er der mere end nok sider i bufferpuljen til at tilfredsstille forespørgslen, så BCHR ikke giver nøjagtigt tal om hukommelsestryk. Du kan endda se, at BCHR ikke engang ville falde, når der er hukommelsestryk. Alle disse er blevet forklaret i Fantastisk SQL Server-debat om BCHR

PLE-output, du sendte, virker virkelig lav, men vi kan ikke bare bruge en tæller til måle hukommelsestryk. PLE er mere indikation af I / O-aktivitet på serveren. Det kunne være muligt, at PLE faldt på grund af tung I / O-aktivitet. Hvis du bemærker, at mål- og total serverhukommelse stadig er den samme. Hvilket er godt tegn.

For Edition upto 2008 R2. Du kan bruge nedenstående tællere

  1. SQLServer: Buffer Manager – CheckpointPages / sec:

  2. SQLServer: Buffer Manager – Memory Grants Afventer:

  3. SQLServer: Buffer Manager – Målserverhukommelse:

  4. SQLServer: Buffer Manager – Total serverhukommelse

  5. SQLServer: Buffer Manager – Gratis sider

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

  7. SQLServer: Buffer Manager – Side forventet levetid

For SQL Server 2012 onwards få af buffer Pooltællere er udfaset, og så vi er nødt til at bruge Memory Manger-tællere

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

  2. SQL Server: Memory Manager – Total Server Memory (KB)

  3. SQL Server: Memory Manager- Free Memory (KB)

  4. SQL Server: Memory Manager – Database Cache Memory (KB)

  5. SQLServer: Buffer Manager – Gratis sider

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

  7. SQLServer: Buffer Manager – Sidens forventede levetid

Bemærk, hvis du har tung diskaktivitet, så glem ikke at henvise også Diskrelaterede tællere. Opret et datasamlersæt , og lad det køre i 4-5 timer, når belastningen på systemet er i top, og tilføj derefter øjebliksbillede af datasamleren i dit spørgsmål. Derefter kan vi afgøre, om SQL Server har brug for mere hukommelse eller ej.

Personligt er 8G lidt mindre RAM i betragtning af arbejdsbelastning og OS-krav i disse dage. På bagsiden af dit hoved skal du altid tænke på at øge RAM.

Svar

vi skal se på SQLServer: Buffer-cache-hitforhold

Hvis dette forhold er mindre end 95%, end serveren er under hukommelsestryk

Håber det hjælper,

Dette er ikke det, der helt sikkert hjælper dig med selv at bestemme hukommelsesflaskehalsen. Snarere hvad jeg foretrækker er at indsamle dataene til nedenstående tællere mindst en dag i den tunge belastning / arbejdstid.

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 

Det bedste ville være baseline SQL-serveren som foreslået Tilbage til det grundlæggende: Optagelse af baselinjer på produktions-SQL Servere , som også indsamler de nødvendige perfmon-tællere sammen med ventestatistikker for ethvert problem ..

Desuden er 8 GB RAM muligvis ikke det, der passer til dagens env, men igen afhænger det af, hvad der er belastningen på systemet sammen med størrelsen på databaser, der hostes på forekomsten \ forekomster.

Skriv et svar

Din e-mailadresse vil ikke blive publiceret. Krævede felter er markeret med *