Performance aspecten in een (R)DBMS – Deel 3

Performance aspecten in een (R)DBMS.  Deel 3: Hardware eisen

Hardware

Naast alle maatregelen die genomen moeten worden om het systeem zo efficiënt mogelijk te schrijven (m.b.t. vele aspecten, zoals performance, maar ook onderhoudbaarheid, testbaarheid, etc.) zijn er nog de eisen die aan de hardware gesteld mogen worden. Monitor regelmatig de computer waar de database server op draait. Probeer bottlenecks in het gebruik van CPU, memory, IO of netwerkbelasting op te lossen voordat ze een probleem geworden zijn. Let hierbij ook op de verdeling van de IO over de verschillende schijven (mogelijk is 1 schijf zeer zwaar belast en de andere schijven nauwelijks). Bij een computer met meer CPU’s moet gelet worden op de verdeling van de capaciteit over deze processoren. Als de database server maar 1 CPU zou gebruiken en er verder niet veel op deze machine draait, dan staan mogelijk de 3 andere CPU’s niks te doen. Een richtlijn voor de CPU belasting: deze mag niet hoger zijn dan 75% op de drukke tijd van een drukke dag.

Let hierbij ook op wat er verder aan toepassingen op dezelfde server draait. Zijn daarbij toepassingen die (overdag) incidenteel een zeer hoge belasting geven, dan zullen de gebruikers van de andere systemen op dat moment een slechte performance ervaren. Hetzelfde kan gebeuren wanneer (incidenteel of permanent) het netwerk zeer zwaar wordt belast.

Naast de (database) server kan ook het netwerk de performance beïnvloeden. Een overbelast LAN of een communicatielijn via een langzame modem of via internet tussen client en server zal beslist nadelig zijn op de door de gebruiker ervaren performance van het systeem.

Memory toekennen aan server (tabellen in memory, in memory databases)

Veel winst kan ook behaald worden door de computer waarop de database server staat, uit te rusten met veel main memory en dit memory ook aan de database server toe te wijzen. Dit stelt de server in staat om veel gebruikte gegevens in memory te houden zodat hiervoor geen fysieke IO meer nodig is.
Bekijk altijd de hoeveelheid geheugen van de computer en hoeveel hiervan werkelijk gebruikt wordt. Als op deze computer alleen een database server draait, wijs dan al het geheugen dat niet voor het operating system nodig is toe aan de database server.
Is fysieke IO een bottleneck in het systeem, bekijk dan of extra memory plaatsen en dit toewijzen aan de database server mogelijk is om dit IO probleem op te lossen.

Er zijn soms (per product verschillende) mogelijkheden om kleine, veel gebruikte tabellen of (het hoogste niveau van) indexen “vast” in memory te plaatsen. Dit geeft waarschijnlijk weinig extra performance verbetering omdat het DBMS toch al de meest gebruikte pagina’s in memory houdt, dus de pages van deze tabellen waarschijnlijk ook.

Het verste gaan in dit opzicht de “in memory databases” [zie ook 9 en 10]. Hierbij zitten alle gegevens permanent in main memory. Dit voorkomt niet alleen de IO maar ook nog de overhead in de server om te kijken of de gegevens al in memory staan. Enkele leveranciers van deze producten claimen een performance die tien maal beter is dan een gewoon RDBMS waarbij de gegevens toch al geheel in memory geladen zijn. Dit soort RDBMS is natuurlijk het meest interessant voor niet te grote databases die wel zeer intensief gebruikt worden.

Naast de memory instellingen kennen de DBMS producten nog vele andere parameters die de performance (positief of negatief) kunnen beïnvloeden. Deze parameters zijn zo leveranciers¬afhankelijk dat ze buiten het kader van dit artikel vallen. Een cursus of handboek Systeem Administratie of Performance en Tuning van de betreffende leverancier en enige ervaring met het product zal de DBA in staat stellen om het systeem verder te tunen.

Performance analyse en testen

Testen en testdatabases

Ondanks al het, veelal preventieve, werk dat hierboven beschreven is zullen zich toch hier en daar performance problemen voordoen. Deze zullen vaak niet geconstateerd worden door de programmeur tijdens zijn unit/programmatest omdat hij meestal met heel weinig gegevens in de database test. Om performance problemen in de productieomgeving te voorkomen zullen dan ook specifieke performancetesten op een database met een inhoud op productiegrootte nodig zijn. Als hiervoor de productiedatabase gebruikt kan en mag worden is dat ideaal. Soms mag het niet (i.v.m. privacy, etc.) maar kan wel een kopie van de productiedatabase gebruikt worden nadat de meest gevoelige gegevens (medewerkers, klanten) anoniem gemaakt zijn door naam en adres te wijzigen in bijvoorbeeld “naam_”, “straat_”, etc.

Voor een nieuw systeem is geen productiedatabase aanwezig maar als er ook een conversie vanuit een bestaand systeem gebouwd moet worden zal deze conversie, getest op een kopie van de productiedatabase, ook een goede omgeving opleveren voor het uitvoeren van een performance test.

Als ook dit niet mogelijk is zal een testdatabase opgebouwd moeten worden door tabellen te vullen met statements zoals

teller = 0
 while teller < 10000
 begin
 teller = teller + 1
 telchar = 
 insert into klant (nummer, naam, straat, huisnr, etc.)
 values (teller, “naam”+telchar, “straat”+telchar, teller modulo 100, etc.)
 insert into order
 values. . . .
 end

Het is lastig om hierbij een testdatabase op te zetten met een verdeling van de gegevens die enigszins overeenkomt met de werkelijkheid (als die al bekend is op dat moment). Verder zal de database zo gevuld moeten dat aan de validatie-eisen wordt voldaan, dit om andere fouten in de programmatuur te voorkomen. Dit alles is erg veel werk, maar voor een groot systeem met hoge performance-eisen onvermijdelijk.

Performance analyses

Als, tijdens testen op bovenstaande database of in productie, toch nog performance problemen geconstateerd worden dan zullen deze geanalyseerd moeten worden. Tijdens het herhalen van de test kunnen een aantal zaken gemeten worden.

Als een programma (of een stored procedure) een groot aantal stappen bevat, bouw dan “displays” in tussen elke stap (of de belangrijkste stappen). De display (met stap-id, tijd, sleutelwaarden, etc.) kan in plaats van naar het scherm eventueel ook naar een tijdelijke tabel die later geanalyseerd wordt. Deze analyse geeft de stap die de meeste tijd kost (relatief ten opzicht van wat verwacht mag worden!) en dus het grootste probleem veroorzaakt. Bedenk dat het mogelijk is dat aan de stap die het meeste tijd kost niets te verbeteren valt maar dat er andere stappen zijn die wel sneller kunnen.

De betreffende stap, mogelijk een ingewikkeld select statement, moet verder geanalyseerd worden. Het RDBMS’en heeft mogelijkheden voor het tonen van:

• de wijze waarop de optimizer de query heeft uitgewerkt
• de doorlooptijd en CPU tijd
• de IO (fysiek naar schijf of logisch naar pages in memory) voor elke tussenstap.

Bekijk hoe reëel deze keuzes en waarden zijn ten opzicht van wat als de meest ideale oplossing gezien wordt door de DBA. Mogelijk kiest de optimizer een verkeerd pad en moet de query wat anders geschreven worden of opgesplitst worden om het probleem op te lossen. Mogelijk wordt een tabelscan uitgevoerd en kan een extra index soelaas bieden. Bij veel fysieke IO kan het toewijzen van meer memory aan de database server mogelijk helpen. Verder uitwerking van dit onderwerp is te productafhankelijk. Hiervoor is een cursus of handboek van de betreffende leverancier dan ook noodzakelijk.

Houdt bij het oplossen van de performance problemen een goede prioriteit voor ogen. Het heeft geen enkele zin om zeer incidenteel gebruikte functies (jaarwerk) te versnellen van 60 naar bijvoorbeeld 45 minuten of zelfs weinig zin als dit naar 20 seconden zou kunnen. Begin dus bij de grote problemen in de veel gebruikte functies; pak daarna de grote problemen in weinig gebruikte functies en de kleine problemen in veel gebruikte functies aan. De kleine (performance) problemen in weinig gebruikte functies zijn waarschijnlijk niet de moeite om opgelost te worden. Als er daarna nog steeds een algemeen performance probleem is, dan is het mogelijk efficiënter om wat extra hardware (snellere processor, meer memory) te kopen dan nog tijd in deze problemen te steken (hardware is bij deze laatste categorie problemen al snel goedkoper dan de tijd van een DBA). Dit is natuurlijk ook afhankelijk van de situatie: draait het systeem op 1 locatie of bijvoorbeeld op 1000 bankkantoren en moet dus 1000 maal de hardware worden gekocht.

Naast de mogelijkheden van het RDBMS voor performanceanalyse zijn er ook nog producten van andere leveranciers die hierbij kunnen helpen. Zo biedt Performance Studio van Rational de mogelijkheid om de SQL statements te tracen die van de client naar de server gaan, het antwoord (resultset), returnstatus, begintijd en eindtijd te bekijken etc. Ook kan met dit product de belasting van een groot aantal (1000) gebruikers op de server gesimuleerd worden door 1 maal een serie van enkele transacties uit te voeren en dit via het gewenste aantal sessies (bijv. 1000) tegelijkertijd na te spelen.

Het is belangrijk om in een vroeg stadium van het project een dergelijke test met enkele voor dit doel geschreven transacties uit te voeren om te controleren of de betreffende architectuur en de geplande hardware het (maximaal) verwachte aantal transacties inderdaad kan verwerken. Mocht dit niet het geval zijn dan kan nu nog actie worden ondernomen.

Samenvatting, conclusie en aanbevelingen

Dit artikel beschrijf een groot aantal aspecten waarmee de DBA (en de applicatiearchitect) van een systeem te maken krijgt in de opzet van zijn systeem. Door met deze punten rekening te houden is een goede performance mogelijk maar nog niet gegarandeerd. De beschreven punten zijn nog algemeen en niet toegespitst op een specifiek product (RDBMS) met weer specifieke mogelijkheden en beperkingen. Een cursus of handboek voor het tunen van het op het project gebruikte RDBMS zal dan voor een verdere diepgang ook noodzakelijk blijven. De punten in dit artikel zullen een DBA echter wel helpen bij de algemene opzet (architectuur) van het systeem en de basiskennis geven voor een leveranciersspecifieke cursus of handboek.

Het is belangrijk om in een vroeg stadium van het project een performance test met enkele specifiek voor dit doel geschreven transacties uit te voeren om te controleren of de gekozen architectuur en de geplande hardware het (maximaal) verwachte aantal transacties inderdaad kan verwerken.

Lees hier artikel 1 en artikel 2 over performance aspecten in een (R)DBMS

Literatuur

1. Loonen, Gegevenskoppelingen in een 4GL/RDBMS omgeving. Database Magazine 1996/8.
2. Loonen, Gebruik van afgeleide gegevens in ontwerp en bouw. Database Magazine 1997/1.
3. Loonen, Modelleren van subtypes. Database Magazine 1999/1.
4. Loonen, Naamgeving van objecten in een RDBMS. Database Magazine 1998/4.
5. Loonen, Mutatierapportage, de tijdgeest van de database. Database Magazine 1999/3.
6. Loonen, Het schrijven van een nette WHERE clause. Database Magazine 1997/7.
7. Loonen, Gegevensmodel van een distributed data dictionary. Database Magazine 1997/4.
8. Loonen, Ontwikkelstraat, hergebruik door inzet van architectuur. Software Release 2000/7-8.
9. Smit e.a., In memory-database, einde van een religiestrijd? Database Magazine 2000/3.
10. Lans, R.F. vd, Tijd was rijp voor veelbelovend TimesTen. Database Magazine 2001/6.

Toon Loonen is als consultant werkzaam bij Cap Gemini Ernst & Young. Hij is bereikbaar via e-mail: toon.loonen@cgey.nl of toon.loonen@inter.nl.net.