InnoDB

De OBA website laadt dankzij de reverse-caching-proxy best snel.
Maar niet altijd.
Dus heb ik de mouwen nog maar een keer opgestroopt.
Anders dan de gemiddelde wordpress site wordt de OBA site zeer frequent ge-update, eigenlijk nog vaker dan nu.nl
Het zijn niet alleen de nieuwe berichten en af en toe wat nieuws in de widgets eromheen, het zijn ook de updates van de “aantal reacties” tellers die bij elk bericht horen. Binnen wordpress moet een nieuw bericht eerst aangemaakt worden, dan wordt het nog twee keer ge-update om de publicatiedatum en de auteur goed op de voorpagina te krijgen. Comments worden in groepjes geteld, elke 10 minuten een groepje van +/- 10 blogs.
Het kan dus gebeuren dat de webserver het druk heeft met updates, net op het moment dat de cache ververst moet worden.
Dat merkt de bezoeker dan, want in plaats van 1 seconde duurt het dan opeens veel langer voor hij antwoord krijgt.
Nu dacht ik dat het iets te maken had met drukte.
Maar als ik zat te wachten op een nieuwe pagina, zag ik meestal een systeem dat het helemaal niet druk had.
Wat is dat apparaat in godsnaam aan het doen ?

WordPress gebruikt een database, MySQL om alles op te slaan wat moet worden onthouden. De webserver zelf onthoudt niks. “Content-free” noemt men zoiets.
Er komt een bezoeker, en die wil de 75 meest recente berichten per auteur zien. Dat betekent dat de webserver aan de database opdracht geeft om een lijstje te maken van alle postst die aan die criteria voldoen, zodat PHP daar een strak vormgegeven opsomming van kan maken.
Normaal gaat dat heel snel, want de database cached ook. Maar als er net een update geweest is, is die cache ge-invalideerd, en moeten de gegevens daadwerkelijk van disk worden gelezen.
Dat kost gemiddeld 5 seconden, heb ik gemeten. ( MySQL kan dat voor je bijhouden in de slow-query-log ).
5 Seconden langer wachten is niet erg, maar wat gebeurt er als de bezoeker iets vroeger komt, en de update nog bezig is ?
Dat hangt af van de database die je gebruikt. MySQL kan gebruik maken van verschillende “storage engines”. De storage-engine bepaalt hoe de gegevens fysiek worden opgeslagen. Aan het resultaat van de query kun je niet zien welke storage-engine gebruikt is.
MySQL gebruikte oorspronkelijk een storage-engine die erg snel is, en zuinig met geheugen : MyISAM.
MyISAM leunt sterk op het bestandssysteem van Windows/Linux/OSx/whatever. Elke tabel is een file.
MyISAM is ideaal voor WordPress, want het werkt het best als de bulk van de verzoeken leesopdrachten betreft, en een kleine minderheid schrijfopdrachten.
Wat doet MyISAM als meerdere clients tegelijk opdrachten geven ?
Voor leesopdrachten is dat natuurlijk geen probleem. Iedereen krijgt gewoon hetzelfde antwoord.
Maar als er 1 of meerdere schrijfopdrachten tussen zitten, is er wel een probleem.
Wie eerst, en wat wordt er gelezen ? Before-image of after-image ?
En hoe zit het met “transacties” ?

Transacties.
Stel, de computer van de bank voert de opdracht uit om geld over te boeken van rekening A naar rekening B.
190 Miljard of zo, geen klein bedragje.
Hij schrijft 190 miljard af van de rekening van de ECB en….
De heimachine van BAM raakt een ondergrondse stroomkabel.
Heel Zuid-Holland zonder licht.
En wat erger is :
190 Miljard lost in hyperspace en rellen in Athene.
Dat wil je niet, en veel programmeurs hebben daar lang geleden al iets op bedacht.
Het heet : transacties.
Transacties zijn bewerkingen die altijd geheel worden uitgevoerd of geheel worden teruggedraaid.
Daardoor valt er nooit geld tussen wal en schip. ( ooit hebben studenten een truukje gevonden om een geldautomaattransactie terug te draaien : vraag een aantal briefjes papiergeld, neem ze allemaal op 1 na, de geldautomaat slikt het overgebleven briefje weer in en draait de transactie terug – de truuk werkt inmiddels niet meer )
MyISAM kent geen transacties, want wordpress is geen bank. WordPress heeft een snelle database nodig die draait op goedkope hardware.
Dat is dus het nadeel van databases die wel transacties ondersteunen : het kost meer rekenkracht.

Maar soms zijn transacties ook handig voor mensen die nooit geld uitlenen of het zelfs niet hebben, en daarom is het prettig dat het gratis MySQL ook een transactiebewuste storage-engine kent, InnoDB.
MyISAM hanteert de volgende strategie bij concurrerende lees/schrijf verzoeken op dezelfde tabel :
Hij sorteert ze en plaatst alle schrijfverzoeken in een queue.
De tabel wordt gelocked, en alle schrijfverzoeken worden eerst afgehandeld. Pas als de laatste schrijfopdracht fysiek op schijf staat, wordt de lock gereleased, en komen de leesopdrachten aan de beurt.
In dat “fysiek opgeslagen” zit volgens mij de oorzaak van de wachttijden die we als bezoekers van de website soms opmerkten.
Fysiek opgeslagen wordt door niet alle operating-systems even serieus opgevat, maar in principe moet een harddisk die in slaapstand staat dus eerst op toeren komen…
In die tijd kunnen er dus veel leesverzoeken binnen komen.
Het is wel zo ingesteld dat de caching-reverse-proxy alle behalve het eerste leesverzoek gewoon “stale” informatie levert, maar 1 bezoeker zal staan te wachten. En in een statistisch onverklaarbaar groot aantal gevallen ben ik die ene bezoeker.

InnoDB kent wel transacties, en heeft een meer verfijnd locking mechanisme. Er worden geen hele tabellen gelocked, maar individuele records. Voor OBA betekent dat dat verzoeken nu kunnen worden afgehandeld in de volgorde van binnenkomst, zodat de lezers minder lang in de rij hoeven te wachten. ( Bij InnoDB worden alle dababases bij elkaar in één groot bestand gepropt, waarvan alleen InnoDB de indeling kent. )
Dus ik heb de hele OBA database gisteren omgezet naar InnoDB : ( je kan per tabel aangeven welke storage-engine MySQL moet gebruiken )
Het aanmaken van de lege nieuwe database doe je door de settings van de oude database te dumpen en met de tekstverwerker MyISAM te vervangen door InnoDB.

mysql> create database nieuwe_database;
 mysql> GRANT ALL PRIVILEGES ON nieuwe_database.* TO 'yyy'@'zz' IDENTIFIED BY 'xxxxx';
prompt> mysqldump --create-options -d -u root -p oude_database > /home/jan/create-oba-db
mysql> source /home/jan/create-oba-db;
prompt> sudo service apache2 stop
 prompt> mysqldump -t --order-by-primary -l -u root -p oude_database > /home/jan/populate-oba-db
 prompt> sudo service mysql stop
 pas de logfile configuratie aan :
 prompt> sudo nano /etc/mysql/my.cnf
 verwijder logfiles :
 prompt> sudo rm /var/lib/mysql/ib_logfile0
 prompt> sudo rm /var/lib/mysql/ib_logfile1
 prompt> sudo service mysql start
 prompt> mysql -u root -p
 mysql> use nieuwe_database;
 mysql> source /home/jan/populate-oba-db;
 prompt> sudo nano /xxx/xx/wordpress-xxxx/wp-config.php
 prompt> sudo service apache2 start

Het verwijderen van de InnoDB logfiles was nodig, omdat we grotere logfiles nodig hadden. InnoDB werd incidenteel al gebruikt.
Voor InnoDB moet je in my.cnf het een en ander instellen, want hij heeft toestemming nodig om een enorme bulk geheugen te reserveren.

De komende tijd zal moeten blijken of de site inderdaad sneller reageert vlak na een update.

Read Offline:
This entry was posted in Wordpress and tagged , , , , . Bookmark the permalink.

11 Responses to InnoDB

  1. Grutte Pier says:

    Goede en juiste analyse, als ik het zo lees. Wederom puik werk!

  2. beheerder says:

    Ik ga bijna blozen.

    Niemand heeft er wat van gemerkt, denk ik. Het was in de nacht van maandag op dinsdag rond 0:00 en het duurde maar een minuut of 10.
    Als je apache afstopt, blijft nginx de website gewoon tonen vanuit de cache, alleen inloggen of reageren lukt niet meer. Daar kwamen we laatst per ongeluk achter bij Ina’s website. Het hele ding bleek in cache te zitten, tm de oudste VKblog verhalen.

  3. Jezzebel says:

    Beetje te technisch voor mij, maar het klinkt goed.
    Ben altijd blij met de berichten van OBA dat er weer iets gefixt is.
    Thanks!
    .

  4. beheerder says:

    Veel te technisch voor de gemiddelde bezoeker van OBA, ook al probeer ik het altijd een beetje populair te formuleren. Mensen die echt snappen waar het over gaat, komen misschien over een half jaar eens kijken, als ze via Google op zoek zijn naar informatie over….
    Als ik iets schrijf, krijg ik soms minder bezoekers dan de dagen ervoor
    Ik was vandaag in gesprek met http://www.anneliesje.nl/articles/320/waarom-ik-gadgets-test-en-over-nagellak-schrijf Die heeft net zulke ervaringen

  5. j de kat says:

    ‘n kleine geit die verder nix met de uiteenzetting heeft te maken:
    “De hijmachine van BAM…”
    Is dat een nieuw woord voor het mannelijk geslachtsdeel?

  6. j de kat says:

    P.S. Onder blogs A-Z kan ik al maanden geen verwijzing meer vinden naar Maria Trepp, of haar Passagenproject. Haar blogs verschijnen wel op het actuele overzicht. Hoe kan dat? Ik weet niet of er meer zo zijn…
    Sterkte met dit sisyfuswerk.

  7. beheerder says:

    klopt.
    Het woord kriebelde aan mijn ogen, maar ik dacht : het heeft niks met de hei te maken en er kwamen wat mailtjes tussendoor, dus toen had ik het al gepubliceerd voor ik het opgezocht had. Jammer.

    Ik zal Ina vragen hoe het zit met Maria Trepp.

  8. @j de kat: Het blog van Maria heet: Kunst Wetenschap Politiek en is onder de K terug te vinden.

  9. Appelvrouw says:

    Ik heb het gelezen omdat het boeiend geschreven is. Natuurlijk de heimachine van Bam een mooi voorbeeld.
    Verder vooral bewondering voor jou en Ina.

  10. Glaswerk says:

    Knap werk.
    Ik doe het je in de verste verte niet na.

  11. beheerder says:

    Gelukkig maar. Ik hou er niet van om steeds nagebootst te worden.

Leave a Reply

Your email address will not be published.