WordPress von seiner besten Seite

Eine Monitoring-Meldung machte uns letzte Woche auf unseren externen Hosting-Server aufmerksam, dem so langsam die Swap-Partition voll lief. Ungewöhnlich für ein System, das eigentlich kaum Last generieren sollte…

Beim genaueren Hinschauen zeigte sich, dass der MySQL fast den kompletten RAM belegte. Also kurz in die Serverüberwachung von PhpMyAdmin geschaut mit einem ungewöhnlichen Ergebnis…

1,1 TB Traffic nach 25h Uptime? Whut?

Spannend auch, dass von den 1,1TB insg. 1,0TB auf eingehenden Verkehr entfiel und nur 119GB gesendet wurden. Interessant für einen SQL-Server mit insg. nur 1,7GB Daten + Indizes. Und der Apache2 dümpelt mit einigen KB/s vor sich hin. Der Query-Log zeigte, dass offenbar ein WordPress-System für diesen Traffic verantwortlich war. Gesamtgröße der Datenbank waren jedoch nur 51MB. Zum Test mal kurz die Präsenz mittels htaccess offline genommen, das Ergebnis war recht eindeutig – der Traffic ging schlagartig um über 99,9% zurück.

Was war passiert? Offenbar schreibt das „dezentrale“ Cron-System von WordPress bei jedem Aufruf der Seite den Cron-Eintrag in der wp_options-Tabelle neu. Und anscheinend durch einen Fehler im Design war dieser Eintrag bereits 32MB groß – bei durchschnittlich 1.500 Besuchen am Tag mit täglich 10.000 – 30.000 Hits wurden die gleichen 32MB also recht häufig hintereinander überschrieben, wodurch dieser absurde Traffic zustande kam.

Glücklicherweise kann WordPress aber offenbar damit leben, wenn dieser Eintrag gelöscht wird und initiiert ihn danach neu. Also gelöscht, das Ergebnis war recht eindeutig:

Und nun? Drei Tage später ist der Eintrag schon wieder auf gruselige Größen angewachsen:

SELECT length(option_value) FROM `wp_options` WHERE
option_name = "cron"

934519

Wie kommen binnen drei Tagen fast 10.000 Zeichen zustande? Ein kleiner Blick in den Inhalt offenbart 4.303 identische Einträge:

a:1:{
    s:23:"nice_cron_version_check";
    a:1:{
          s:32:"a4f7c5794142991da8bc9309736db8c3";
        a:3:{
            s:8:"schedule";
            s:6:"weekly";
            s:4:"args";
            a:2:{
                s:7:"current";
                                     s:5:"1.0.4";
                s:6:"latest";
                N;
            }
            s:8:"interval";
            i:604800;
        }
    }
}

Danke für nichts, nice_cron_version_check! Offenbar wird hier irgendein Cron entweder vom Template oder von WordPress selber nicht korrekt angelegt, eine Google-Suche danach liefert genau einen Treffer…

Immerhin hat sich die Ladezeit der Seite von initial 4 Sekunden nun wieder auf einige Millisekunden verkürzt… 😉