Migratie update

2020 February 37 min read
Joep van de Laarschot

Het is alweer twee weken geleden dat we verhuisd zijn naar een nieuwe hoster. Sindsdien zijn we een hoop dingen tegengekomen. De meeste dingen waren relatief klein en vooral verbeteringen voor onszelf, maar we kwamen twee problemen tegen die groter waren. Tijd voor een migratie update.

t0slmanffcg
Foto door Fredy Jacob op Unsplash

Probleem 1

Tijdens de verhuizing kwamen we een groot probleem tegen. Het jodiBooks Beauty dashboard werd na een tijdje heel traag. We konden het die avond al terugleiden naar een tekort aan geheugen voor de database. We wisten alleen niet hoe we het moesten oplossen.

Poging 1

Die avond hebben zoveel mogelijk onnodige programma's verwijderd, zodat er meer geheugen vrijkwam. Dat zorgde er in ieder geval dat het langer duurde voordat het dashboard traag werd, maar het probleem was niet opgelost.

Poging 2

De week daarop verplaatste Joep het blog naar een eigen server. Daarmee kwam er weer meer geheugen vrij voor de database. Dit leek aanvankelijk te werken, maar ook nu was het probleem nog niet helemaal opgelost. Dit verplaatsen van het blog leverde Joep wel meer hoofdpijn op, zie probleem 2.

Poging 3

De jodiBooks bestaat uit verschillende applicaties. Die applicaties (apps) kun je op verschillende manieren op een server laten draaien. Je kunt ze allemaal in dezelfde "app pool" zetten of iedere app in zijn eigen app pool.

iis scherm met geheugen per app pool
Geheugengebruik van de losse app pools.

Door ze bij elkaar te zetten wordt het instellen makkelijker. Je hoeft bijvoorbeeld maar een keer een verbinding te maken tussen de app pool en de database. Door ze allemaal in een eigen app pool te zetten, moesten we dus meerdere verbinding maken.

Dit had wel een voordeel. Je kunt namelijk per app pool zeggen hoe lang ze in het geheugen mogen blijven. Applicaties die we alleen 's nachts draaien of maar een keer per uur, gooien we daarna dus zo snel mogelijk uit het geheugen.

Was dat de oplossing? Het helpt, maar soms moeten we toch echt die andere applicaties draaien. Op die momenten hadden we nog een probleem.

Poging 4

De database zelf vraagt om geheugen. Sterker nog, bij de standaardinstelling neemt hij alles wat vrij is. Zodra de website dan iets nodig heeft, is er geen geheugen meer vrij en wordt het traag. Althans, we denken dat dat gebeurd.

Gelukkig is er een instelling waarbij je het geheugengebruik van de database kunt beperken. Dat is voor ons nu nog geen probleem, maar wel als het aantal gebruikers toeneemt. Maar daar hebben we al een ander plan voor. Daarover later meer.

Geheugen in een server
_"Geheugen in een server"_ Foto door Stef Westheim op Unsplash

Poging 5

Joep dacht dat hij met poging 3 de toewijzing van geheugen aan apps had verbeterd. Op het eerste gezicht misschien wel, maar tijdens het typen van dit post en het maken van de plaatjes, viel iets op.

Door de apps te scheiden, is er in totaal meer geheugen nodig. Dat was onverwacht, maar achteraf gezien wel logisch, want de applicaties delen een hoop code. Blijkbaar gaat Windows daar slimmer mee om dan we dachten.

Als we alle gebruikers (de dagelijkse applicaties) bij elkaar optellen, komen we op 980 MB uit. Dat zijn dan 5 van de 8 applicaties die wij draaien.

Een eerste verbetering is het samenvoegen van de gebruikersapplicaties en onze interne applicaties. Het "dagelijks" geheugengebruik gaat dan naar 455 MB. De interne applicaties hebben 340 MB nodig. Samen is dat 795 MB.

iis scherm op test server
In rood het geheugengebruik bij een splitsing test-ao (gebruikersdeel) en test-terminate (ons deel). In blauw het geheugen als alles samen in een pool zit.

Door alle applicaties bij elkaar te zetten, ging het geheugengebruik verder omlaag naar 645 MB voor alle 8 de applicaties! Dat is een flinke winst van minstens 34%.

Probleem 2

Zoals al eerder genoemd, was de eerste poging om geheugen vrij te maken het verplaatsen van het blog. Hiervoor hebben we een aparte server ingericht. Deze server host alleen het blog en de database van dat blog.

Maar ook deze server werd af en toe zo traag dat hij niet meer reageerde. Het blog kon dan niet geopend worden en soms kon de server niet eens gereset worden. Ook hier bleek het geheugen een probleem te zijn.

Poging 1

Joep had een handleiding gebruikt om alle software te installeren en in te stellen. Ieder onderdeel van de WordPress "stack" (alle benodigde software) gebruikt namelijk geheugen en dat kun je op Linux allemaal zelf instellen en optimaliseren.

De gebruikte handleiding was geschreven voor een server met meer geheugen, dus moest er hier en daar wat geïmproviseerd worden met de waardes. Na het vinden van een andere handleiding, stelden we het geheugengebruik van de verschillende software (Nginx, PHP, Redis) naar beneden bij.

Poging 2

Na een week gebruikt, draaiden we een script dat laat zien waar je de database instellingen kunt optimaliseren. Ook dit moet het geheugengebruik optimaliseren.

Dit werkte een week heel goed. Totdat Joep begon met het documenteren van onze hosting. De server liep weer vast.

Poging 3

Dus, wat nu? Joep kreeg gelukkig een ingeving. Wat als het swap geheugen te klein is? Een computer (server, laptop, smartphone) heeft altijd een beperkte hoeveelheid geheugen (gigabytes of GB's). Moderne smartphones en laptops hebben ergens tussen de 4 en 8 GB. Onze server heeft 1 GB!

Als het geheugen vol is, gaat het besturingssysteem (iOS, Android, Windows, MacOS, Linux) op zoek naar een andere plek om data op te slaan. Dat doet het op de harde schijf in het swap-geheugen. De harde schijf is veel trager dan het geheugen, dus je wilt dit eigenlijk alleen in geval van nood gebruiken.

In ons geval willen we dingen die we niet vaak gebruiken daar neerzetten. Maar onze server bleek helemaal geen swap te hebben. Vreemd, want AWS zegt in hun documentatie dat je altijd swap moet gebruiken en wij hebben hun image gebuikt, waarin swap uitstaat?! Nouja, dat weten we nu tenminste.

top applicatie laat geheugengebruik zien

Het geheugengebruik van onze Linux server. KiB Mem is geheugen, KiB Swap is Swap.

Verbeterpunten

Of we de geheugenproblemen nu hebben opgelost weten we nog niet. Daarvoor moeten we deze week afwachten. Wat we wel weten is dat we nog een hoop kunnen winnen door de databases op hun eigen server te zetten. Dat staat op ons architectuur lijstje.

Terwijl Joep bezig is geweest met het geheugen en logging van de servers, heeft Emma verbeteringen aan de app gedaan. Hiervoor moeten we ook de API updaten, dus er komt weer een update aan.

Leerpunten

Dit was onze eerste migratie. En voor een eerste keer ging het best soepel. Het geheugenprobleem was wel echt een bummer. Vooral omdat we hier expres veel voor getest hadden. We hebben hier van geleerd om nog exacter de uiteindelijke serveromgeving te simuleren.

Allereerst moeten we alle applicaties aanzetten. Tijdens het meten waren een paar in slaapstand gegaan. Daarnaast is meten op een thuisserver pas stap 1. Daarna moeten we dezelfde test doen op een server in de cloud, waar de software ook gaat draaien.

Ook blijven we leren en nieuwe inzichten krijgen door deze blogposts en update te schrijven. Door te zoeken naar woorden en plaatjes, om iets moeilijks relatief simpel te vertellen, help je jezelf ook om iets beter te begrijpen. En dat is misschien wel het grootste leerpunt!