Performance Tuning

Uge 21: Performance Monitoring

Men hvordan kan du så bruge disse elementer og den nye viden til at komme i gang med at monitorere og afhjælpe performance problemer på SQL serveren? Det tager jeg lidt hul på i dag med performance monitoring.

Så er det ved at være sidste udkald i denne rækkefølge af indlæg. Og over de sidste 5 måneder har jeg forsøgt at hjælpe dig godt i gang med at forstå nogen af de forskellige aspekter af performance tuning på SQL serveren.

En baseline

Mange sidder foran deres computer og har performance problemer på deres SQL server. Nogen i højere grad end andre og de har måske ingen ide om hvordan man kommer i gang, og finder den underliggende årsag til problemet, eller hvordan man løser det.

Svaret kan være irriterende for nogen, men det gælder om at indsamle og monitorere information om den nuværende situation og sammenligne den med en baseline for at identificere de mest fremtrædende årsager til problemerne. Ja, det er lidt irriterende, der skal være en baseline – ellers bliver det en famlen i blinde for at løse problemerne.

Ideen bag denne tilgang er den jeg synes er den mest simple. I første step indsamles data og nøgletal for SQL serveren og dens installation og konfiguration. Denne indsamling bliver til baseline. I næste afsnit herunder, kommer jeg lidt ind på forslag til hvilke data der skal indsamles.

Efter baseline er etableret, er det muligt at gennemse disse for performance problemer – der findes en række værktøjer til dette som jeg kommer ind på lidt senere i dette indlæg.

En lille ændring ad gangen – jeg skriver det lige igen – en lille ændring ad gangen. Det er nok det vigtigste at huske. Hvis der bliver ændret for mange ting på een gang, ved du ikke, hvad der er afhjulpet problemet, eller, hvis det skulle ske, om en af delene har givet en dårligere performance. Det er her hele arbejdet ligger.

Efter ændringen er blevet implementeret skal man måle på data igen – de samme som ligger til grund for baseline. Disse skal så sammenlignes for at se om det har givet den forventede performance optimering. De nye indsamlede data bliver så den nye baseline og processen starter forfra. Det er også vigtigt at bestemme sig for, hvornår godt er godt nok. Man kan hurtigt blive vugget ind i en proces, hvor man hele tiden finder små tilpasninger, ændringer, tweaks og andet godt, der liiiiige giver det sidste.

Indsamling af baseline data

Når man skal indsamle baseline data og metrikker for performance, er det vigtigt at vide hvilke elementer der bør være med. Der findes så mange forskellige metrikker og målinger i SQL serveren gennem forskellige værktøjer, at man ikke kan tage dem alle med. For ikke at komplicere tingene for meget, kunne et bud på de første elementer til en baseline være:

  • Specifikke SQL Server performance målinger
  • Wait Statistics
  • I/O statistics

De specifikke performance målinger kommer herunder og i næste uge zoomer jeg ind på de to andre (wait statistics og I/O statistics). At få fat i de specifikke (og relevante) performance målinger kan gøres bl.a. via Performance Analysis og Logs (PAL) værktøjet som du kan finde her. Det er et værktøj, som er bedst til on-prem installationer, og med nogen år på bagen, men virker fint til formålet.

PAL værktøjet har nogen forberedte skabeloner som man kan anvende. Disse skabeloner kan importeres direkte til Windows Performance Monitor og output bliver en meget stor HTML fil med rappoter der viser mulige elementer med performance problemer. Et eksempel kunne se ud som nedenstående.

Ved opstart af arbejdet med performance problemer, kan det være godt at starte med det samme værktøj hver gang og kende det til fulde.

Til brug for azure installationer kan man anvende azures indbyggede performance counters fra portalen og her analysere sig frem til problemerne. Microsoft har også gjort rigtig meget ud af at komme med forbedringsforslag til bl.a. manglende index eller index der ikke bør være der.

I azure er det samme fremgangsmåde – etabler baseline – og her kan man direkte også gemme sine performance analyser og genkøre dem – ligesom med PAL værktøjet ovenfor.

Opsummering – performance monitoring

I dag har jeg forsøgt at hjælpe dig godt på vej i arbejdet med at etablere en baseline og hvilke værktøjer man kan anvende til det formål.

I næste uge skriver jeg som sagt lidt mere om Wait og I/O statistics.

Husk at skrive dig på maillisten nedenfor, så du ikke misser næste udgave af denne blogserie. Jeg lover dig kun at sende en mail, når der er nyt i denne serie.

Få besked om næste indlæg

Skriv dig gerne op til at modtage en mail, ved næste indlæg. Det kan du gøre nedenfor.



Marketing stuff

Our emails contain marketing stuff, so we need to give you some fine quality fine print: brianbonk will use the information you provide on this form to email you with updates and marketing. You can change your mind at any time by clicking the unsubscribe link in the footer of any email you receive from us, or by contacting us at help@brianbonk.dk. We use Mailchimp as our marketing platform. By checking the box to subscribe, you acknowledge that your information will be transferred to Mailchimp for processing, and that we may process your information in accordance with these terms.

Følg mig på Instagram

Leave a Reply

Your email address will not be published. Required fields are marked *

en_USEnglish