Performance tuning: een veel besproken item en in veel gevallen het eerste vraagstuk waar nieuwe klanten mee aankloppen. De invalshoek of klacht is meestal de snelheid van de database. Op zich een logische stap om dan in actie te komen. Om ad hoc en op korte termijn direct zichtbaar verbetering te realiseren wordt vaak gegrepen naar het uitbreiden van resources. En, met databases in de cloud en auto-scale, of “fully managed”, worden deze resources geheel automatisch voor je bijgeschaald. Wat alleen niet gemanaged wordt zijn de kosten. Want dat is namelijk ook het verdienmodel van de hedendaags populaire DBaaS-oplossingen. Alle reden om databaseperformance eens proactief onder de loep te nemen.
Performance tuning: In meerdere opzichten een winstpakker!
Kortetermijnoplossing
Een logische eerste stap die gezet wordt om snel verbetering te realiseren is het uitbreiden van resources, CPU, RAM, etc. Dit kan echter ook een 
valkuil zijn omdat bij eigen (onpremise, hosted, datacenter, private cloud) omgevingen bij hardware uitbreidingen dit ook gevolgen kan hebben voor je softwarelicenties. Dus buiten extra kosten voor de resources, ga je ook nog eens aanzienlijk meer betalen voor je licenties, die veelal zijn gebaseerd op x per core of per CPU. Groter “gevaar” is bij je database in de cloud en bij bijvoorbeeld auto-scale opties dat de cloud-provider al resources voor je heeft bijgeschaald, dat bedoelen zij namelijk met “fully managed”. En de financiële gevolgen kunnen aanzienlijk zijn. Zoals een startup in maart 2020 ondervond bij een interne test met Google Cloud Run + firebase op GCP. Zie afbeelding.
Misverstand
Wat vaak een misverstand is dat cloudproviders niet bedoelen met fully managed dat er een data engineer aan de andere kant zit die iets vind van het datamodel, je applicatiekoppeling en I/O gebruik, database-onderhoud doet en advies geeft over indexeringstrategie. Met fully managed bedoelen zij dat je database altijd beschikbaar is en automatisch meeschaalt met de groei of het gebruik. En dat lossen ze op door het toevoegen van extra resources. Dat is ook het verdienmodel van de gangbare DBaaS-oplossingen. De providers en DBaaS-leveranciers hebben geen belang met een efficiënt ingerichte en actief gemanagede database-omgeving. Ook bij clouddatabases verdient de database de nodige aandacht. Met name om de meest wenselijke balans tussen high performance en kosten te realiseren en behouden.
Proactief tunen
Als we de vijf belangrijkste oorzaken voor slechte performance weten, kunnen we hierop anticiperen en voor de muziek uitlopen en voorkomen dat er überhaupt vertraging gaat optreden of onnodige resources worden bijgeschaald.
Wat zijn de meest voorkomende oorzaken?
- Groei database en dataverkeer
- Inefficiënt datamodel
- Niet of slecht database-onderhoud
- Negeren van updates en patches
- Veranderende omstandigheden in de omgeving
- Database verhuizen naar de cloud
- Applicatie-update
- Hardware
- Etc
De laatste twee oorzaken zijn relatief logisch en duidelijk aanwijsbaar op het moment dat dit speelt. In deze blog gaan we iets dieper in op de eerste drie onderwerpen:
Groei dataverkeer en database
Door toenemend gebruik, opslag van data, groei van gebruikers en een omvangrijker applicatielandschap wordt de database meer belast. Belangrijk om te ontdekken is welk onderdeel van de database het zwaarst belast wordt.
Inefficiënt datamodel
We hebben er al eerder een blog over geschreven dat de invloed van datamodellering vaak wordt onderschat. Zaken als indexeringstrategie, datatypen en volgorde kolommen dienen goed aan te sluiten bij de actuele belasting van de database. Veel databases worden nog vaak opgeleverd zonder gedegen indexeringstrategie of er is inmiddels sprake van een verouderde indexering. Het is aan te raden om een indexeringstrategie te implementeren of om de huidige indexering te reorganiseren. De keuze van datatypen dient zorgvuldig te worden gemaakt. Wanneer bijvoorbeeld huisnummers moeten worden opgeslagen kan doorgaans worden volstaan met een smallint of int en zorgt een bigint voor verspilling van ruimte.
Ook de volgorde van kolommen of velden kan van wezenlijke invloed zijn op de uiteindelijke prestaties van de database. Vaak wordt er voorbijgegaan aan het feit dat de specifieke kenmerken van kolommen (verplicht/niet-verplicht) en het datatype (fixed/variable width) de daadwerkelijke opslag op de data-pages beïnvloeden. Er zal ook regelmatig onderhoud moeten plaatsvinden op de indexering. Statistieken opfrissen, de indexen reorganiseren of zelfs verwijderen en waar nodig opnieuw aanmaken. Tabellen die vaak worden gemuteerd zullen hier veel baat bij hebben.
Database-onderhoud
Wanneer er sprake is van achterstallig database-onderhoud zal het huidige resourcegebruik niet representatief zijn voor datgene waartoe de configuratie en hardware in staat zouden kunnen zijn. Door het uitvoeren van insert-, update- en delete-statements op tabellen zullen de indexen gefragmenteerd raken. Dit houdt in dat er ruimte is gereserveerd voor een index maar er staat geen bruikbare informatie meer op die plek. Komt dit fenomeen alleen op bepaalde databaseplatformen voor? Nee, op alle platformen. MySQL, MariaDB, Oracle, Sybase, SQL Server, PostgreSQL en zelfs NoSQL varianten zoals MongoDB. De methode om dit op te lossen varieert per platform. Meestal zijn er standaard voorzieningen aanwezig maar vaak zijn die ingrijpend en blokkeren de normale databaseprocessen, zoals het opslaan van nieuwe records. Er zijn echter manieren, met en zonder third-party tooling, om die ingrijpende acties te minimaliseren of zelfs te voorkomen.
Meten is weten
Performance tuning begint met meten. Een goede monitoring van de database-omgeving is essentieel om de vinger op de zere plek of plekken te kunnen leggen. Daarnaast kun je door structureel te monitoren vergelijkingen maken waardoor veranderingen in de omgeving boven water kunnen worden gehaald. Tenslotte kunnen er in de logfile van de database meldingen voorkomen die om actie vragen. Het is verstandig de logfile op regelmatige basis (dagelijks) te inspecteren om mogelijke problemen op tijd te signaleren.
Wat wil je minimaal meten?
1 Performance counters (Windows) of PCL/Perf (Linux)
Gebruik deze tools zodat systeemdata verzameld kunnen worden mbt CPU, Memory en disk usage. Dit helpt om data te verzamelen over een langere periode en een beter inzicht te krijgen wat er is gebeurd in plaats van wat er exact nu, op dit moment, gebeurt. Zo kunnen er trendanalyses gedaan worden en pijnpunten makkelijker getraceerd worden.
2 CPU usage
CPU usage kijkt naar de workload die er ligt op de database-omgeving. Belangrijke informatie die hieruit opgehaald kan worden over een langere periode is wat de verschillen zijn tussen bepaalde periodes. Gebeurt er ’s nachts bijna niks en overdag heel veel? Of zien we daar nauwelijks verschil?
3 Memory usage
Lees- en schrijfacties gaan via Memory (RAM), en bouwen een daarin een buffer op. Als er een hoge load is op een systeem, is er dan wel genoeg memory om deze load te kunnen dragen? Wordt er vooral gelezen of juist veel geschreven? Zijn er piekmomenten op een dag? Is die piek de oorzaak van een traag systeem op dat moment? Dit zijn allemaal vragen waar een deel van het antwoord al te halen is uit de gegevens van de memory usage.
4 Disk I/O
Deze informatie is belangrijk om te onderzoeken of er vertraging zit in het lezen en schrijven, hoeveel er geschreven en gelezen wordt. Onderliggende oorzaken kunnen bijvoorbeeld zijn slechte disks, inefficiënte diskperformance, redundante I/O vanuit applicaties en slecht performande-queries.
5 Aanvullende data
Uiteraard kun je nog aanvullende data verzamelen die je wat meer diepgaande informatie geeft over bijv queries, deadlocks, transactions, buffers etc.
Bouwstenen
Grafana en Prometheus zijn bouwstenen waarmee monitoring kan worden opgezet. Door exporters te scrapen in Prometheus en dashboards toe te voegen aan Grafana ontstaat een monitoringoplossing. Die exporters en dashboards zijn vaak op GitHub terug te vinden. Evenals diverse plugins.
Kant en klare monitoringoplossingen
Er zijn ook kant en klare (open source) monitoringoplossingen beschikbaar in de markt voor verschillende type database engines (PostgreSQL, MySQL varianten, MariaDB, maar ook DBaaS als Aurora, RDS en Azure SQL database), zoals Percona Management en Monitoring (PMM).
DBaaS-restricties
Nu zal je in een DBaaS-situatie veelal geen toegang hebben tot OS. En zul je creatief moeten zijn om toch voldoende informatie uit je omgeving te destilleren om er op te kunnen acteren. Maar ook vanuit DBaaS-engines kun je veel activiteiten monitoren waarop je proactief kunt reageren.
Efficiënt data-engineering
Wij leven in een wereld die meer en meer door data gedreven is. Goed beheer van je dataplatform (in de cloud) wordt dan ook steeds crucialer. Een goede database-expert weet precies hoe de nieuwste tooling werkt, voelt zich als een vis in het water bij zowel opensource- als gelicenceerde databaseomgevingen en vindt het oplossen van complexe databasepuzzels een feest. Maar wat is nu de route naar effectief database-engineering? Om een aantal handvatten aan te reiken hebben we daar een whitepaper over geschreven. Download hier onze whitepaper.
Meer weten?
Wil je advies hoe je performanceproblemen vóór kunt zijn? Meer weten over een onderhoudsplan of indexeringstrategie? Wil je kiezen voor een DBaaS-oplossing, maar je weet nog niet wat de beste keuze is? Neem gerust vrijblijvend contact met ons op!