Wir haben Probleme mit unserem Rackspace-WordPress-Server, der nach dem Senden einer E-Mail bei mittlerem Datenverkehr ausfällt.
Die Serverspezifikationen sind:
CPU 2 vCPUs
RAM 2 GB
System Disk 80 GB
Network 240 Mb / s
Disk I/O Good
Läuft:
Centos 7.0
Wordpress 4.3.1
Httpd 2.4.6
PHP 5.4.11
MariaDB 5.5.41
Die Installation ist, soweit ich das beurteilen kann, ziemlich standardmäßig und die Datenbank ist ziemlich standardmäßig, indiziert und ziemlich klein. Wir verwenden auch WordPress-Objekt-Caching.
Laut New Relic verbringt die Site bei normalem Datenverkehr etwa 80 % der Zeit in PHP, 15 % der Zeit im externen Web und nur einen kleinen Prozentsatz in der Datenbank. Die durchschnittliche Standard-Seiten-App-Zeit beträgt etwa 800 ms, was mir langsam erscheint.
Wenn Sie einen Belastungstest mit 250 Verbindungen in 1 Minute durchführen, dauert es zunehmend länger, bis die Verbindungen hergestellt sind. Nach etwa 30 Minuten kommt es zu einer Zeitüberschreitung und der Server reagiert nicht mehr (selbst wenn der Datenverkehr wieder abnimmt). Um wieder aktiv zu werden, ist ein Hard-Reboot erforderlich.
Ich kann mit Putty keine Verbindung herstellen und die Homepage schwankt zwischen einer Zeitüberschreitung und der gefürchteten Meldung „Fehler beim Herstellen der Datenbankverbindung“.
Beim letzten Test mit dem Rackspace-Überwachungsagenten scheint die CPU kurz vor dem Absturz zu 100 % ausgelastet zu sein, der verwendete Speicher erreicht seinen Höchstwert bei etwa 1,6 GB, während der freie Speicher auf etwa 100 MB abfällt. Es sieht so aus, als würden auch etwa 2 GB Swap-Speicher (insgesamt 4 GB) verwendet. Die Standardauslastung scheint bei etwa 15 % CPU, 800 MB Speicher und 400 MB Swap zu liegen.
Unsere Apache-Konfiguration legt keines der folgenden Elemente fest (keine Dateien darin /etc): Timeout, KeepAlive, MaxKeepAliveRequests, KeepAliveTimeout; daher gehe ich davon aus, dass die Standardwerte verwendet werden.
Ich habe mir die MariaDB-Einstellungen angesehen:
innodb_buffer_pool_size = 1400M
max_user_connections = 0
Was nicht die Ursache zu sein scheint.
Ich habe auch das Leistungsschema aktiviert, weiß aber nicht wirklich, wonach ich suche. Ich bin nicht einmal sicher, ob die Datenbank das Problem ist.
Ich bin versucht, die Instanz zu aktualisieren, hätte aber lieber einen klareren Überblick darüber, wo der Engpass liegt und was den Server zum Absturz bringt, anstatt ihn einfach nur langsamer werden zu lassen.
Irgendwelche Ideen, wo ich anfangen könnte? Es scheint viele Optimierungsmöglichkeiten und jede Menge Informationen zu geben.
Antwort1
Eine genaue Überwachung ist bei jeder Art von Veranstaltung von entscheidender Bedeutung. Wie wir sehen, kam die Wahrheit ans Licht:
Beim letzten Test mit dem Rackspace-Überwachungsagenten scheint die CPU kurz vor dem Absturz zu 100 % ausgelastet zu sein, der verwendete Speicher erreicht seinen Höchstwert bei etwa 1,6 GB, während der freie Speicher auf etwa 100 MB abfällt. Es sieht so aus, als würden auch etwa 2 GB Swap-Speicher (insgesamt 4 GB) verwendet. Die Standardauslastung scheint bei etwa 15 % CPU, 800 MB Speicher und 400 MB Swap zu liegen.
PHP ist bekanntermaßen sehr CPU-intensiv. Sie haben die gesamte verfügbare CPU und fast den gesamten verfügbaren RAM verwendet.
Sie sollten zunächst Maßnahmen ergreifen, um das Problem zu beheben, z. B. Opcode-Caching (z. B. Zend OPcache) und Datei-Caching (z. B. W3 Total Cache WordPress-Plugin). Wenn diese nicht helfengenug, dann ist es Zeit, die Instanz zu aktualisieren.
Antwort2
Wahrscheinlich lassen Sie einfach zu viele Prozesse gleichzeitig laufen, haben nicht genügend Arbeitsspeicher und der Swap-Speicher wird durcheinandergebracht. Es kann sein, dass etwas anderes blockiert, aber kümmern Sie sich zuerst darum und sehen Sie dann, wo Sie stehen.
Sie haben uns nicht gesagt, ob Sie mod_php oder etwas wie php-fpm verwenden. Letzteres kommt mit der Last besser zurecht, aber stellen Sie in beiden Fällen sicher, dass Sie nicht mehr PHP-Prozesse ausführen, als Sie Speicher haben. Sie werden wahrscheinlich keinen Leistungsvorteil daraus ziehen, mehr als 5 oder 10 Prozesse auszuführen, aber insbesondere die Standardausführung von mod_php wird viel mehr ausführen, als Sie Speicher haben. Führen Sie außerdem alle 30 Anfragen oder so Prozesse erneut aus. Wenn Sie Ihrer Datenbank und Ihrem Betriebssystem 1 GB zuweisen, werden Ihre anderen GB wahrscheinlich nicht 10 WordPress-Prozesse verarbeiten. Sehen Sie sich an, wie viel Speicher sie beanspruchen, und berechnen Sie es mit etwas Spielraum. Normalerweise sollten Sie keinen Swap verwenden.
Sehen Sie sich Ihre Keep-Alive-Einstellungen an. Bei Apache sollten Sie diese Einstellungen wahrscheinlich entweder deaktivieren oder auf 1 Sekunde einstellen. Nginx kommt mit Keep-Alive viel besser zurecht. Tatsächlich ist dies der einzige wirklich wichtige Grund, warum Nginx bei einer PHP-Anwendung wie WordPress wahrscheinlich eine bessere Leistung erbringt (allerdings auf Kosten einer weniger angenehmen Konfiguration). Dies ist bei Ihren Tests höchstwahrscheinlich kein Faktor, ist aber bei echten Browsern wichtig.
100 % CPU überrascht mich. Verwenden Sie top, um zu sehen, was es nutzt. Denken Sie auch daran, dass 100 % oft 100 % eines Kerns bedeuten. Möglicherweise sehen Sie nur, dass ein Cron-Job anläuft, was bei WordPress normalerweise kein „Cron“ als solches ist, sondern Jobs werden zusätzlich ausgeführt, während Webanforderungen verarbeitet werden. Fehlendes Opcode-Caching könnte ebenfalls eine hohe CPU-Auslastung verursachen.