Over de downtime van 13/14 juni 2009

Vorig weekend was FOK! ruim een dag down. Helaas kwamen er wat klachten over de communicatie vóór en tijdens de downtime, dus daar gaan we in het vervolg opener mee om. Om gelijk goed te beginnen, staat hieronder een samenvatting van wat er allemaal is gebeurd bij dat onderhoud, waarom het zolang duurde, en wat we nog gaan doen om FOK! nog sneller te maken.

De schijven waarop de database bewaard wordt, moesten vervangen worden omdat ze voor 98% volzaten _{ergens anders stond 97%, maar dit was eigenlijk 98%}. De drie oude schijven waren 73 GB per stuk, de nieuwe (weer drie) 146 GB. De database moest meeverhuizen, en dat kun je op twee manieren doen: de bestandjes kopiëren of de inhoud uit de bestandjes halen en de bestandjes later opnieuw opbouwen. Wij besloten dat tweede te doen, want ondanks dat het iets meer tijd kost, bood het een aantal voordelen zoals defragmentatie (binnen de bestanden zelf) en het snel aanpassen van veel indices, waarover later meer¹.
Helaas ging het kopiëren van de inhoud van de bestanden al mis na 3GB: ’segmentation fault’ wat zoiets betekent als ‘als de software geen bug bevat dan is je hardware kapot’. Andere machine geprobeerd, zelfde verhaal. Toen de software maar eens geüpdatet, en toen ging het gelukkig wel goed. Zelfs sneller dan verwacht: binnen een uurtje klaar.

Dan de disks verwisselen. Daarvoor moest wat geschroefd worden. “Oh”, zei ik, “nu moet ik geen schroefje laten vallen want dan verdwijnt hij in dat rooster”. “Is niet erg”, zei Iteejer, “dat rooster kan open”. Nog geen minuut later mocht Iteejer het rooster openmaken Nieuwe schijven erin, netjes de RAID(5)-array aanmaken, partitioneren en formatteren, wat mapjes aanmaken, rechten op de mapjes goedzetten, en de backup kon worden teruggezet. Een mooi taakje om ’s nachts te laten lopen en zelf te gaan slapen. Iteejer zou vroeg opstaan om FOK! weer aan te zwengelen.

Helaas voor mij kwam Iteejer er ’s ochtends (vroeg!) achter dat er ’s nachts toch iets was misgegaan, en stelde mij daarvan op de hoogte zodat er van uitslapen niets terechtkwam. Sommige cruciale tabellen waren nog leeg. De backup zou toch wel volledig zijn aangemaakt? Totaal zonder enig idee van de oorzaak zijn we weer naar Amsterdam vertrokken.

De oorzaak werd al snel duidelijk: het backupprogramma maakt lekker grote pakketjes aan, wat gunstig is voor de snelheid bij het terugzetten. Helaas was één zo’n pakketje net te groot geworden, waardoor het terugzetten was gestopt. Kwestie van het configuratiebestand openen, max_allowed_packet vergroten, en nog een keer proberen met de gegevens die nog niet waren teruggezet. Dat ging prima, en ’s middags kon de site weer online komen.

Het viel direct op dat de site wel erg traag was. Dat heb je normaalgesproken de eerste minuut altijd omdat hij dan zijn geheugen (16GB) nog moet vullen en tot die tijd de harddisks veel te vaak moet raadplegen, maar dit keer bleef het traag. Uit de errorlog bleek al snel de oorzaak: er was iets misgegaan met InnoDB-logfiles. En daarvoor moest de site weer offline. Alle InnoDB-tabellen (waaronder de enorme tabel met alle forumposts) moesten door een programma worden nagelopen, wat tot in de avonduren duurde en waarvan geen duidelijke voortgangsmeter beschikbaar was. Pas nadat de forumposts-tabel was nagekeken had ik een idee van hoelang het nog ging duren; minutenwerk. En inderdaad: niet lang daarna kon FOK! weer online en werkte het weer prima

¹Zoals beloofd nog iets over indices. Daar valt veel snelheidswinst mee te halen als ze nog niet of niet goed ingesteld zijn. Indices zijn gesorteerde lijsten, en als je iets zoekt (zoals een naam in een telefoonboek) of iets nodig hebt dat gesorteerd is (zoals de forumposts in een topic die je op tijd wilt sorteren) dan ben je blij dat je zo’n al gesorteerde lijst kunt gebruiken. _{Overigens, voordat Replique (deels ten onrechte) de schuld krijgt van traagheid, de indices voor de forumposts waren prima, de winst is behaald op de andere subsites.} Voor elke tabel moet je apart die indices instellen, en het is niet op voorhand duidelijk welke indices het beste zijn. Er zijn in totaal honderden tabellen, en bij elke tabel is het aantal mogelijke indices enorm. En ze allemaal instellen is geen optie: die lijsten moeten worden bijgehouden en nemen ruimte in, dus als je ze niet nodig hebt dan wil je ze ook absoluut niet hebben.
Een voorbeeld waar indices groot verschil hebben gemaakt, is de userhistory op de frontpage. Het bleek dat het opvragen hiervan bij sommige users wel een minuut duurde. Toen dit duidelijk werd, is die functie enige tijd uitgeschakeld geweest. Nu met de juiste index duurt het nog maar milliseconden. Zo groot kan het verschil dus zijn, maar vaak is het verschil kleiner. De afgelopen maand zijn er ruim 50 wijzigingen doorgevoerd, waarvan ongeveer de belangrijkste helft tijdens de downtime, een klein deel overdag en de rest ’s nachts (zie oa. hier en hier).

Maar vaak is het niet zo eenvoudig om een index toe te voegen en direct resultaat te zien. Soms moet ook de software aangepast worden of moeten de gegevens net iets anders worden opgeslagen. Dat is oa. gebeurd bij het fotoboek en de eerdergenoemde frontpageuserhistory. Het effect is gelukkig merkbaar: was FOK! tot een maand geleden nog wel eens langzaam, sindsdien ben ik dat niet meer tegengekomen. Ook wat getallen die de database zelf bijhoudt, geven aan dat hij het rustiger heeft.

Momenteel is Breuls bezig met nieuwe software voor de frontpage, FOK!sport en FOK!games. Dat is de volgende stap met verbeteringen op databasegebied. Het is te hopen dat we daarmee alle traagheid voorgoed achter ons laten.