Versie 12 Mrt 2004 Versie 11 Feb 2004



Dovnload 359.02 Kb.
Pagina1/3
Datum24.07.2016
Grootte359.02 Kb.
  1   2   3

Pag van


Performance


Versie 1.12 Mrt 2004

Versie 1.11 Feb 2004

Versie 1.10 Jun 2003

Versie 1.9 Mar 2003

Versie 1.8 Jan 2003

Versie 1.7 Nov 2002

Versie 1.6 Juli 2002

Versie 1.5 Jan /Feb 2002

Versie 1.4 Sep 2001

Versie 1.3 Mei 2001

Versie 1.2 feb 2001

Versie 1.1

Auteur: Joachim Verhagen, dec 2000, jan 2001


Gebruik van dit document


Lees eerst het algemene gedeelte. Hierin staan de principes en hoe problemen te vinden.

De delen over specifieke databases herhalen niet wat er in het algemene gedeelte staat.

Voer het algemene gedeelte ook uit. Vaak ligt de oplossing bij het operating systeem en niet bij de database. Alleen het database specifieke gedeelte is niet voldoende.

Inhoud


Performance 1

Gebruik van dit document 1

Inhoud 1

Inleiding 1

Analyse en oplossingen 2

Geheugen 3

Physical disk 4

CPU 5


Netwerk 6

Database resources 7

Database specifiek 7

SQLBASE 7

SQLServer 7 & SQLServer 2000 9

Oracle 32

Informix 39

Operating systeem specifiek 47

NT server (inclusief opvolgers) 47




Inleiding


Performance problemen ontstaan doordat één van de resources van het systeem te traag is en een bottleneck vormt. In het ideale geval is het traagste element de gebruiker.




  • De eerste stap bij performance problemen is ontdekken waar de performance problemen zijn. Dit is de eerste en belangrijkste stap.

    • Vraag wanneer er problemen optreden, of er een relatie is met bepaalde programma's of bepaalde tijden.

      • Wees specifiek:

      • Als een klant op iets bepaalds klikt duurt het zo lang voor het resultaat komt.

        • Gebeurt dat altijd?

        • Gebeurt het op bepaalde tijden?

        • Gebeurt het als iemand anders wat bepaalds doet?

        • Gebeurt het op bepaalde werkplekken?

      • Hoe lang hoort dit te duren? (Eventueel navragen bij de DBS helpdesk. Sommige batch processen horen ’s nachts te worden gedraaid.)

    • Doe indien nodig navraag bij verschillende personen. Er kunnen verschillende klachten zijn en het zou vervelend zijn als alleen een minder belangrijke opgelost wordt.

    • Noot: Het programma is altijd met alles traag betekent niets. Dat kan betekenen dat het opstarten van modules traag is of dat de favoriete module van degene die de melding doet traag is. Er bij gaan staan en kijken kan duidelijkheid geven.

  • De volgende stap is meten terwijl het probleem optreedt. Het grootste deel van dit document is daar aan gewijd.

    • Zoek eerst of het probleem op de server of op de client ligt.

    • Kijk vervolgens welke resource het probleem is.

  • De laatste stap is wijzigingen aanbrengen om het probleem op te lossen.

Het probleem kan liggen op :



  • de server

  • de client

  • het netwerk.

Als het probleem op de server ligt kan het liggen aan :



  • De instellingen van de server

  • Overige programma’s die draaien op de server

  • De instellingen van de database

  • Oude of geen update statistics op de database

  • Gebrek aan resources op de server

Locks of latch problemen op de database kunnen aan de server instellingen liggen of aan het programma.


Als het probleem op de client ligt kan het liggen aan:

Als het probleeem bij het netwerk ligt, kan het liggen aan:



  • Configuratie netwerk

  • Ingredienten netwerk



Analyse en oplossingen

Op zowel client als server kunnen de volgende resources bekeken worden (op windows 95/98/millenium/2000 met de systeem monitor / system monitor, op windows NT met de performance monitor,

Op unix voor CPU: ps, sar, vmstat, mpstat, iostat

geheugen: ps, sar, vmstat

schijf : sar, iostat

netwerk: netstat

Sommige unix versies hebben ook eigen tools, die meestal makkelijker werken.
Hieronder zal ik namen van performance monitor gebruiken. De principes gaan voor ieder operating systeem op.


Geheugen

Meten


  • Memory: Available Bytes

  • Memory: Pages /sec (vmstat: page: po of pout = pages out)

pages/sec moet continu een lage waarde hebben. Alleen bij opstarten of afsluiten van een programma mag een hoge waarde voorkomen.



Commando voor het bepalen totaal aanwezig geheugen voor verschillende operating systemen





Operating systeem

RAM Geheugen commando

Digital Unix/ compaq tru 64 etc. (DEC Alpha)

/usr/sbin/uerf –r 300 | grep –i mem

Solaris

prtconf | grep –i mem

Linux

free

HP-UX

swapinfo –tm

AIX

lsattr –El mem0

Windows

properties system, general tab



Commando voor het bepalen geheugen in gebruik op dit moment voor verschillende operating systemen





Operating systeem

RAM Geheugen commando

Digital Unix/ compaq tru 64 etc. (DEC Alpha)

/sbin/hwmgr

Solaris

Vmstat

Linux

xosview

HP-UX

vmstat -n

AIX

/bin/vmstat

Windows

task manager of performance monitor

Noot bij vmstat:

Altijd vmstat periode count gebruiken en het eerste record negeren, omdat dat sinds het opstarten van de machine is

Commando voor het bepalen Paging / Swap ruimte voor verschillende operating systemen





Operating systeem

paging

Page files

Digital Unix/ compaq tru 64 etc. (DEC Alpha)

swap -l

swap -l

Solaris

swap -l

swap -l

Linux

free

grep swap /etc/fstab

HP-UX

swapinfo –t –a -m

swapinfo –t –a -m

AIX

lsps -a

lsps -a

Windows

Performance monitor

properties system, advanced tab, performance options, change

Oplossingen:


  • Sluit overbodige programma’s

  • Verlaag de disk cache van databases. (Kijk in de database hoofstukken hoe dit moet.) Hierdoor is er meer geheugen beschikbaar, maar zal een database meer gegevens van de schijf moeten halen. Page faults zijn echter veel slechter voor de performance dan data van schijf halen.

  • Voeg physiek geheugen toe

  • Soms treden er memory leaks op. Programma's geven geheugen niet terug aan het operating systeem. De enige oplossing hiervoor is regelmatig de machine rebooten. Een keer per maand moet voldoende zjin. (Soms is dit probleem bij nieuwere versies van een programma opgelost, maar de ervaring leert dat er waarschijnlijk een ander memory leak voor in de plaats komt.)

Als pages /sec hoog is, zal tevens de physical disk en de CPU hoog zijn. Los eerst de geheugen problemen op, voordat de CPU en schijf bekeken worden.


Als Available Bytes erg laag is, is er niet genoeg geheugen (physiek geheugen en virtueel geheugen tezamen)

Oplossingen:



  • Breid het virtueel geheugen uit

  • Breid het physiek geheugen uit

Physical disk

Meten





  • PhysicalDisk: % Disk Time

  • PhysicalDisk: Avg. Disk Queue Length (vmstat: b = blocked processes ten gevolge van I/O)

  • iostat : bps (Kbytes/s)

Doe dit zowel voor de schijf met programma’s, de schijf met de temporary directory en de schijf met de databases
Noot voor NT4 : let bij gebruik performance monitor bij waarnemen van “physical disk” er op dat diskperf –y is uitgevoerd op de prompt en daarna de machine herstart. Bij Windows 2000 staat het standaard aan.
Als % disk time > 90 % en er is geen RAID systeem , dan is de schijf een bottleneck.

Als voor langer dan 10 minuten > 50% kan dit ook al een schijf bottleneck betekenen.

Als er wel een RAID systeem is, dan is het van belang te weten hoeveel spindles het systeem gebruikt (zonder RAID is dit standaard 1. Het aantal spindles zal in de documentatie van het RAID systeem staan.)

De Average disk queue length moet minder dan anderhalf keer het aantal spindles zijn.



Een hoog schijfgebruik verhoogt tevens de CPU waarde, omdat de CPU het schijfgebruik aanstuurt. Als beide hoog zijn, los dan eerst het schijf probleem op.

Oplossingen:


  • Als er tevens veel page faults zijn, ligt de bottleneck bij het geheugen. Kijk eerst bij geheugen

  • Update statistics of een rebuild van indexen kan overbodige full table scans voorkomen. Het programma updstats in de dbs programma directory kan dit doen. Meer informatie over update statistics staat in de database specifieke hoofdstukken.

  • Cache schijfruimte in het geheugen, In het bijzonder databases hebben hier mogelijkheden voor. Maak dit echter niet zo groot dat er page faults ontstaan. Page faults zijn veel slechter voor I/O.

  • Verplaats programma’s, temp directory, de data bestanden of log bestanden van de database naar andere schijven, die resources over hebben.

  • Bij 2 schijven: splits data en log

  • Bij 3 schijven: splits data, log en temp

  • Kijk ook bij de database hoofdstukken over de verdeling van bestanden over de schrijven.

  • Schaf een sneller systeem aan (RAID 0) of extra schijven om programma’s, temp directory de data bestanden of log bestanden van de database op te plaatsen.

  • Werk niet met gecomprimeerde schijven



Iets over RAID


Raid combineert een aantal schijven, zodat het er uitziet als één schijf. Tevens doet het iets aan databescherming.

  • RAID 0 of striping: Een bestand wordt over meerdere disks en disk-controllers verdeeld. Zowel lezen als schrijven gaat sneller. Des te meer schijven er zijn, des te groter wordt het effekt. Er is geen extra data beveiliging en als er één disk uitvalt is alles weg van alle schijven. Als performance belangrijk is en de backup strategie voldoende is, is dit een uitstekende oplossing.

  • RAID 1 of mirroring: De data staat een keer op iedere schijf. De lees performance is sneller, omdat gelezen kan worden van de schijf die het minst belast wordt. De schrijf performance is trager, omdat het twee keer moet gebeuren. Zorg in ieder geval dat beide schijven een eigen disk controller hebben, anders wordt de schrijf performance te traag. Bedenk dat ook databases die voornamelijk voor raadplegen worden gebruikt (decision support) nog veel schrijven voor ingewikkelde joins e.d. Het belangrijkste voordeel is natuurlijk dat de data nog veilig is als er een disk wegvalt.

  • RAID 1+0 (ook bekend als RAID 10) of striped mirroring. Hierbij wordt striping uitgevoerd over mirrored disks. De lees performance is vergelijkbaar met RAID 1, de schrijf performance is slechter dan alleen RAID 0, maar beter dan een gewone schijf of RAID 5..

  • RAID 0+1 of mirrored striping. Hierbij word een mirror uitgevoerd over gestripete schijven. Dit is sneller dan RAID 1+0, maar niet zo veilig

  • RAID 3: Striping met een extra parity disk. Systeem om database performance te bederven. Nooit gebruiken.

  • RAID 5: Striping met parity data verdeeld over de schijven. Het is bedoeld om de voordelen van RAID 0 te combineren met data bescherming, zonder meteen twee keer zoveel schijfruimte nodig the hebben. De schrijf performance is beduidend slechter dan RAID 1, maar lezen is sneller. Een vuistregel is dat als minder dan 10% van de I/O schrijven is RAID 5 een goed RAID systeem is. Het is niet echt geschikt voor OLTP databases, zoals wij hebben. Voor decision support databases zijn ze wel geschikt.

Voor schrijven is de snelheids verhouding ongeveer : RAID 0 : RAID 1 : RAID 10 : RAID 5 = 4 : 2 : 2 : 1

Des te meer schijven er in een RAID array zitten, over des te meer schijven wordt de I/O verdeeld en des te sneller de RAID array.
Bij DBS zelf is de I/O bij Talent en Salaris (inclusief uren en verlof registratie) ongeveer 40% schrijven en bij Selligent ongeveer 50% schrijven. (Mochten deze waarden je verbazen, denk er dan even aan dat bij de aanbevolen cache hit ratio van meer dan 95%,, minder dan 1 op de 20 lees acties inderdaad iets van de schijf haalt.)
Conclusies:


  • Als de backup strategie goed genoeg is voor het database gebruik en de tijd nodig om de database weer in de lucht te krijgen niet heel belangrijk , dan is RAID 0 het beste voor de datafiles. Voor onze databases gaat dit vaak op.

  • Als de data bescherming permanent moet zijn is RAID 0+1 het beste voor de datafiles. Dit is wel duurder.

  • Logfiles worden sequentieel geschreven, dus als ze op een eigen schijf staan kan dat beter een gewone schijf zijn. Als ze niet op een eigen schijf staan is RAID 0 weer het beste.


CPU

Meten





  • Processor:% Processor Time (vmstat: cpu: us (=user cpu))

  • Processor: % Privileged Time (vmstat: cpu: sy (=system cpu))

  • Process: % Processor Time q (ps : %CPU)

(Process % Processor Time voor de processen, waar het om gaat (database of programma)

  • pset_info (op Unix: Aantal processors + average load)

Als % Processor Time constant hoger is dan 90% of vaak op 100% komt is er een processor probleem. Als % privileged time hoog is, zijn het achtergrond processen die dit veroorzaken, vermoedelijk page faults of disk activiteit. Als %Privileged time and Process % Processor time laag zijn en % processor time hoog is er een ander programma dat de CPU in beslag neemt.



Commando voor het bepalen CPU gebruik voor verschillende operating systemen




Operating systeem

CPU gebruik totaal

CPU gebruik per processor

Digital Unix/ compaq tru 64 etc. (DEC Alpha)

/usr/sbin/pset_info




Solaris

sar -u

/usr/bin/mpstat

Linux

xosview




HP-UX




/usr/bin/sar -M 5 5

AIX

ps av of iostat 3 20

vmstat

Windows

task manager of performance monitor

task manager of performance monitor

Noot bij vmstat:

Altijd vmstat periode count gebruiken en het eerste record negeren, omdat dat sinds het opstarten van de machine is

Oplossingen:


  • Als tevens er tevens schijf of geheugen problemen zijn, kan dit het CPU probleem veroorzaken. Los eerst de geheugen en schijf problemen op.

  • Een gecomprimeerde schijf is erg slecht voor de performance. (Microsoft noemt tot 500% vertraging bij SQL Server.) Schaf een grotere schijf aan en gebruik geen schijf compressie.

  • Update statistics of een rebuild van indexen kan helpen. Het programma updstats in de dbs programma directory kan dit doen. Meer informatie over update statistics staat in de database specifieke hoofdstukken.

  • Sluit overbodige programma’s af. Kijk ook naar screensavers. Bewegende screensavers zijn overbodig. Let ook op processen die beginnen bij het opstarten en services.

  • Bij een Windows syteem: Configureer de server als applicatie server (en niet als file server)

  • Schaf een sneller systeem aan

  • Werk op een dedicated server (alleen voor de database, geen PDB of BDC of andere services)



Netwerk

Meten





  • Network Interface: Output Queue Length

  • Network Interface: Bytes Total/sec

  • Network Interface: Current Bandwidth

De Output Queue geeft aan of data paketten moeten wachten op de netwerk kaart. Dit moet in principe op 0 staan. Indien dit voortdurend of regelmatig 2 of hoger wordt is de netwerk kaart overbelast. Een nieuwere driver of een nieuwere kaart kan soms helpen. Als bytes total/sec bijna gelijk is aan current bandwidth is het netwerk overbelast. De waarde moet het grootste deel van de tijd lager zijn dan 0.6 De mogelijkheden nu zijn overstappen naar een dedicated server of zelfs overstappen naar een sneller netwerk. Een extra kaart verschuift de bottleneck meestal alleen maar naar de hub/switch, maar als dat in u situatie niet het geval is is dat de goedkoopste oplossing. Let op dat het mogelijk is dat de database de extra netwerk kaart niet gebruikt.


Current Bandwidth geeft de capaciteit van de netwerk kaart aan in bits/s. Controleer of een 10 Mbit/100 Mbit kaart wel op 100 000 000 bit staat. Wijzig de instelling indien nodig


  • Is er een ander programma dat het netwerk belast?

  • Wordt de machine ook als file server gebruikt?

Als het netwerk in het algemeen overbelast is:



  • Snellere netwerkkaarten (controleer dat de kabels het aankunnen)

  • De nieuwste driver installeren voor de netwerkkaart.

  • Switches in plaats van hubs

  • Zorg dat er maar één netwerk protocol gebruikt wordt. (indien de applicaties dat toelaten)


Database resources


Dit zijn objecten als locks en latches. Monitoring hiervan is database afhankelijk.

Trace de waits indien mogelijk.

Bij Informix en SQL Server kan de statistische informatie worden schoongemaakt voor de meting.

Bij Oracle kan specifiek per sessie worden gemeten.





  1   2   3


De database wordt beschermd door het auteursrecht ©opleid.info 2017
stuur bericht

    Hoofdpagina