Een groothandel in bouwmaterialen kreeg elke ochtend dezelfde mail van zijn monitoringdienst: de website was in de nacht onbereikbaar geweest. Overdag deed alles het prima. Dat een website s nachts uitvalt en ‘s ochtends weer gewoon werkt, maakt het lastig te geloven dat er echt iets aan de hand is, en het maakte de eigenaar vooral onzeker over zijn hosting.
De uitval duurde telkens tussen de vier en de twaalf minuten, altijd tussen 03:00 en 03:30. Geen klantklachten, want er is ‘s nachts weinig verkeer. Wel een zoekmachine die de site in die periode af en toe niet kon bereiken, en een boekhoudkoppeling die een paar keer per week faalde. Hieronder het verloop van de zoektocht.
Wat we eerst wilden weten
Bij een terugkerende storing op een vast tijdstip is de belangrijkste vraag niet “wat is er stuk” maar “wat gebeurt er op dat moment”. Iets dat elke nacht op dezelfde klok begint, is bijna nooit toeval en bijna altijd een geplande taak.
We hebben daarom drie dingen naast elkaar gelegd:
- De meetgegevens van de monitoring. Die lieten zien dat de site niet weg was maar traag: verzoeken duurden langer dan dertig seconden en liepen af.
- De logboeken van de webserver rond dat tijdstip. Daar stonden foutmeldingen over verbindingen die niet tot stand kwamen.
- De agenda van geplande taken. Zowel de taken binnen WordPress als de taken die op serverniveau draaien.
De laatste categorie is degene die het vaakst over het hoofd wordt gezien, omdat die niet in het beheerscherm van WordPress zichtbaar is.
Wat we aantroffen
Om drie uur ‘s nachts liepen er drie dingen tegelijk. Ten eerste maakte de hostingpartij een systeemback-up van het hele account, waarbij de database kortdurend op slot ging. Ten tweede startte een back-upplugin binnen WordPress een eigen back-up, die de complete bestandsmap inpakte tot een archief van bijna zes gigabyte. En ten derde draaide er een plugin die ‘s nachts alle productafbeeldingen opnieuw comprimeerde.
Drie zware taken, alle drie ingesteld op het klassieke tijdstip waarvan iedereen aanneemt dat het rustig is. Samen trokken ze de processor en het geheugen van het pakket helemaal vol. De server was niet stuk; hij had het simpelweg te druk om nog een gewone bezoeker te bedienen.
Er zat nog een tweede laag onder. De back-upplugin nam ook mappen mee die er niet in hoorden: een map met oude exports, een kopie van de site die iemand ooit als test had neergezet, en de map met logbestanden. Van de zes gigabyte was ruim de helft ballast.
Wat we hebben veranderd
- De taken uit elkaar getrokken. De hostingback-up bleef op 03:00 staan, de back-upplugin ging naar 01:30 en de afbeeldingsverwerking naar 05:00. Alleen deze verschuiving haalde de uitval al weg.
- De back-up opgeschoond. Overbodige mappen uitgesloten, waarmee het archief terugliep naar iets meer dan twee gigabyte en de taak nog een derde van de tijd kostte.
- De frequentie aangepast. Een volledige bestandsback-up hoeft niet elke nacht; de bestanden veranderen nauwelijks. Dagelijks de database, wekelijks alles. Waarom dat een verstandige verdeling is, staat in de uitleg over hoe vaak u een back-up nodig heeft.
- De geplande taken van WordPress echt gepland. Standaard start WordPress zijn taken pas als er een bezoeker langskomt. ‘s Nachts is dat onvoorspelbaar, waardoor alles zich kan opstapelen. We hebben dat vervangen door een taak op serverniveau die elke vijf minuten kijkt of er werk is. Achtergrond staat in het artikel over geplande taken die niet afgaan.
- De afbeeldingsplugin begrensd op een maximum aantal afbeeldingen per keer, zodat hij niet meer in één ruk door de hele bibliotheek gaat.
Het werk kostte bij elkaar ongeveer twee uur. De nachtelijke uitval was daarna weg en is in de maanden erna niet teruggekomen.
Wat deze case laat zien
Drie dingen zijn breder toepasbaar dan deze ene site.
Een vast tijdstip is een aanwijzing, geen bijzaak. Valt uw site steeds op hetzelfde moment uit, kijk dan eerst naar wat er op dat moment gepland staat. Dat is sneller dan zoeken naar een fout in de code.
Overbelasting ziet eruit als uitval. De monitoring meldde “site niet bereikbaar”, terwijl de site technisch gewoon draaide. Wie alleen op die melding afgaat, gaat de verkeerde kant op zoeken en verdenkt zijn hosting ten onrechte.
Standaardinstellingen stapelen op. Elke plugin kiest netjes een tijdstip midden in de nacht, want dat lijkt beleefd. Met drie plugins die allemaal beleefd zijn, staat er om drie uur een file. Bij het instellen van een nieuwe plugin is het dus zinnig om even te kijken wat er al draait.
Wat u zelf kunt controleren
U hoeft geen beheerder te zijn om hier iets mee te doen. Kijk in uw beheerscherm welke plugins een eigen schema hebben, meestal back-up, beveiligingsscan, afbeeldingsoptimalisatie en soms een importkoppeling. Noteer de tijdstippen. Staan er twee of meer op hetzelfde uur, zet er dan een uit elkaar. Vraag daarnaast bij uw hosting op hoe laat hun eigen back-up draait, en houd dat uur vrij.
Merkt u dat de site regelmatig traag of onbereikbaar is zonder duidelijk patroon, dan is meten de enige weg. Een monitoringdienst die elke minuut kijkt kost een paar euro per maand en levert precies de tijdstempels op waar dit soort onderzoek mee begint. Het uitzoeken zelf hoort bij het opsporen van terugkerende storingen op een WordPress-site, en bij WebMaintor beginnen we bij zo’n melding altijd met de kalender van geplande taken voordat we ook maar één plugin uitzetten.
Concrete volgende stap: zoek op welk tijdstip uw back-upplugin draait en vergelijk dat met het back-upvenster van uw hosting. Staan ze op hetzelfde uur, verschuif er dan één.
