Im letzten Monat fing mein Server zufällig an zu explodieren. Ich hatte eine perfekte Installation, die 9 Monate lang einwandfrei funktionierte, aber im letzten Monat begannen die Auslastung und die Speichernutzung zufällig außer Kontrolle zu geraten.
Es scheint, dass dies durch etwas Äußeres verursacht wird, aber ich habe keine Ahnung, was es sein könnte. Ein Neustart des Servers lässt ihn für einige Minuten bis 18-24 Stunden normal laufen, aber das ist ungefähr das Maximum.
Die Speicherauslastung steigt und steigt und steigt, bis der Apache-Prozess-Core-Dump abstürzt. Die Belastungsspirale steigt auf 20+.
[Tue Jan 05 11:31:22.629436 2016] [core:notice] [pid 1246] AH00052: Kind-PID 8127 Ausgangssignal Segmentierungsfehler (11)
Davor funktionierte dieser Server 9 Monate lang einwandfrei mit Lasten [in top] im Bereich von 0,01 – 0,20.
Auf dem Server läuft das Ein-Klick-WordPress-Installationsabbild von Digital Ocean, er verfügt über 1 GB Arbeitsspeicher und 1 GB Auslagerungsdatei.
Meine Liste aktiver Plugins lautet wie folgt: Blubrry PowerPress, CloudFlare, Disqus Comment System, Jetpack, Login LockDown, Monarch Plugin (Share On Theme123.Net), Nofollow Links, TinyMCE Advanced, Yoast SEO
Keines der Plugins wurde in vielen Monaten geändert.
Auf meinem Server läuft nur eine WordPress-Installation und eine Site. WordPress und Plugins werden immer auf die neueste Version aktualisiert. Es gibt keine größeren Änderungen auf der Website.
Ich hatte in der Vergangenheit zu 100 % bei jeder WordPress-Installation Probleme, bei denen die Seiten durch Brute-Force-Hacking-Versuche auf /xmlrpc.php abgestürzt sind. Ich musste den Zugriff darauf komplett verweigern, obwohl es das Jetpack vermasselt, weil ich es nicht konnte Holen Sie sich Order Allow, Deny to work. Es verursacht entweder 520er an alle URLs auf dem gesamten Server oder es meldet “Bestellung hier nicht erlaubt” im Fehlerprotokoll und es funktioniert nicht. Dies ist ein separates Problem, aber ich wäre sehr dankbar, wenn jemand das auch erklären könnte. Die Erfahrung der Vergangenheit zeigt, dass es in 100 % der Fälle zu abgestürzten Websites führt, wenn xmlrpc.php öffentlich zugänglich bleibt.
Kann jemand helfen? Ich werde hier wirklich verzweifelt, das zerstört meine Seite. Konnte es seit Anfang Dezember nicht länger als 24 Stunden online halten. Niemand hat Antworten.
Enthält Ihre Website viele schwere Bilder?
– DpEN
5. Januar 2016 um 11:17 Uhr
Hallo Kirk, ich habe Cloudflare an und alles drehte sich bis zum Maximum, was das Caching angeht. Ich werde dieses Plugin ausprobieren. DP DE – Meine Website ist nicht super bildlastig, aber Cloudflare würde das auf jeden Fall zwischenspeichern. Ich weiß, dass der Cache funktioniert und gut funktioniert, weil ich in den Cloudflare-Statistiken sehe, dass Cloudflare mehr als 50 % der gesamten Bandbreite (51 %) und weit mehr als 50 % der Anfragen (61 %) einspart. Danke.
– M3498
5. Januar 2016 um 13:56 Uhr
Ich habe das Query Monitor Plugin hinzugefügt. Bisher hat es nur eine langsame Abfrage erkannt. Ich vermute, dass es später viele langsame Abfragen geben wird, aber ich denke, dies ist eher ein Symptom als eine Ursache dafür, was den gesamten Speicher auffrisst. Sobald es beginnt, den gesamten Speicher auszutauschen und zu verbrauchen, wird alles langsam sein. Ich denke, es ist Apache, nicht MySQL, das es zum Absturz bringt und brennt. Gibt es etwas Besonderes, auf das ich in diesem Plugin achten sollte? Vielen Dank.
– M3498
5. Januar 2016 um 14:09 Uhr
Bisher wird von Zeit zu Zeit nur diese Abfrage erkannt:
1 SELECT option_name, option_value FROM wp_options WHERE autoload = 'yes' wp_load_alloptions() wp-includes/option.php:181 + Core 519 0.0287
so langsam. Die meisten anderen Abfragen sind 0,0001 mit gelegentlich 0,0010 oder 0,0012.– M3498
5. Januar 2016 um 14:11 Uhr
@KirkBeard Danke für deinen Beitrag.
– M3498
6. Januar 2016 um 23:15 Uhr