• This forum has a zero tolerance policy regarding spam. If you register here to publish advertising, your user account will be deleted without further questions.

Wordpress hohe CPU Last

I

ianklemm

Guest
Hallo,
Ich habe Wordpress frisch auf einem kleinen VPS mit folgenden Daten laufen:


Code:
2GB RAM, 2vCore, 100GB HDD, 1Gbit Shared, Standort in Frankfurt am Main

Code:
Folgende Software ist installiert:
Code:
Debian 7
Apache 2.2
PHP 5.4
MYSQL Server 5
FCGID
Froxlor (Zur Verwaltung)

Plugins sind keine Installiert und auch das standard Theme nutzen, bringt keine Abhilfe.

Nun zum Problem, wenn ich die Seite aufrufe oder wechsel, sehe, ich per Htop auf dem Server, dass die CPU Last auf 10-60% ansteigt und das obwohl ich der einzige Besucher darauf bin!


Vielen Dank!
 
Und wo ist das Problem?
Der Webserver soll die Seite ja schnellstmöglichen ausliefern.

Diese Last wird für den Bruchteil einer Sekunde erzeugt, HTOP ist aber insofern nicht "realtime" (weil es dann im Nanosekundenbereich pollen müsste).

Kritisch wird es nur dann, wenn die Last permanent so hoch ist, dass Requests nur noch mit sehr großen Verzögerungen bearbeitet werden können.
 
Hi,

Das stimmt, Htop zeigt die Auslastung nicht Realtime an, das habe ich nicht bedacht.

Aber dennoch, sobald ein paar Nutzer auf der Seite sind, steigt die Auslastung auf 100% @beiden Kernen an, und bleibt so auch.
 
Das klingt dann auch schon ganz anders, besonders wenn sie dabei bleibt.
Wie sieht es denn mit den anderen Werten aus?
Kopiere doch bitte mal die ganze Zeile aus top (nicht htop), wenn der Server gerade am Anschlag ist.

Das sieht dann z.B. so aus:
Code:
%Cpu(s):  0.0 us,  0.0 sy,  0.0 ni,100.0 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 st

Die Prozessliste wäre auch ganz interessant, also falls noch andere Prozesse als nur der Apache beteiligt sind (z.B. MySQL).
 
Code:
%Cpu(s): 92.3 us,  6.7 sy,  0.0 ni,  1.0 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 st

Moment, Prozessliste füge ich gleich ein.

Code:
 7496 Ian       20   0  197m  39m 9156 R  11.0  1.9   0:14.23 php-cgi
12357 Ian       20   0  190m  31m 8296 R  11.0  1.5   0:09.21 php-cgi
12358 Ian       20   0  190m  31m 8364 R  11.0  1.5   0:09.90 php-cgi
12359 Ian       20   0  198m  40m 9148 R  11.0  2.0   0:11.52 php-cgi
12429 Ian       20   0  190m  32m 8252 R  11.0  1.6   0:07.48 php-cgi
12449 Ian       20   0  187m  28m 8216 R  11.0  1.4   0:08.76 php-cgi
12459 Ian       20   0  190m  32m 8252 R  11.0  1.6   0:08.99 php-cgi
12450 Ian       20   0  182m  24m 8320 R  10.6  1.2   0:08.55 php-cgi
12465 Ian       20   0  189m  31m 8216 R  10.6  1.5   0:07.95 php-cgi
 
Last edited by a moderator:
Ok, wait hat mich da besonders interessiert, da ich evtl. das Storage im Verdacht hatte (kommt bei vServern jetzt nicht sooo selten vor, dass es da mal hakt).
Ich würde jetzt einfach mal versuchen, dass ich die Last senke, die einfachste Variante wäre z.B. ein Opcache, dann müssen die PHP Skripte nicht jedesmal neu geparsed werden.

PHP scheint ja auch der Flaschenhals bei Dir zu sein.
 
Kann ich irgendwie prüfen, ob der Storage daran schuld ist?

Edit: Gäbe es abgesehen von einem Cache eine andere Möglichkeit die durch PHP erzeugte Last zu verringern?
 
Last edited by a moderator:
Wenn es so gewesen wäre, dann hätte das Bild oben etwas anders ausgesehen.
Dann wartet die CPU nämlich permanent auf Daten und stalled in der Zeit massiv, was sich dann im io_wait Wert ausgedrückt hätte.
 
Ja, ist mir auch gerade aufgefallen.
Soweit ich weiß, ist in PHP 5.5 Opcache eingebaut, ist das richtig? Würde dann ein einfaches Upgrade helfen?
 
Last edited by a moderator:
Ja, das stimmt, wobei Du dann ohnehin gleich auf PHP 5.6 setzen könntest.
 
PHP 5.5 inklusive Opcache ist nun installiert. Aber die Auslastung ist leider immernoch (fast) so hoch.
Ich werde mich aber mal in Opcache einlesen, eventuell muss ich gewisse Optionen noch aktivieren.
 
Hast Du mit Hilfe von phpinfo geprüft, ob opcache auch aktiv ist?
Es ist zwar seit 5.5 standardmäßig in PHP vorhanden, AFAIK aber nicht automatisch aktiv, sondern deaktiviert.

Ich bin einfach mal dreist und verweise auf ein passendes Thema bei Stackoverflow, da dort die akzeptierte Antwort extrem gut ist.
http://stackoverflow.com/questions/17224798/how-to-use-php-opcache
 
Last edited by a moderator:
Ja, ist aktiv. Habe ich geprüft.
Danke für den Link, werde ich mir genauer durchlesen.
Edit: Bei mir war es schon aktiviert, daher musste ich es nicht manuell aktivieren.

Version:
Code:
PHP 5.5.28-1~dotdeb+7.1 (cli) (built: Aug  8 2015 21:58:05) 
Copyright (c) 1997-2015 The PHP Group
Zend Engine v2.5.0, Copyright (c) 1998-2015 Zend Technologies
    with Zend OPcache v7.0.6-dev, Copyright (c) 1999-2015, by Zend Technologies
 
Last edited by a moderator:
WordPress ist ein schrecklicher Ressourcenfresser. Du solltest hier am Kern des Problems ansetzen und WP mit entsprechenden Caching-Plugins ausstatten. W3 Total Cache ist ziemlich gut. Ansonsten gibt es auch Plugins, die solche Plugins determinieren können, die den Ladeprozess in die Länge ziehen (welch Ironie :D).

Unabhängig davon ist PHP-FPM mit NGINX vermutlich auch in deinem Fall eine Möglichkeit, mehr Leistung rauszukitzeln. Das Kernproblem wird aber dein CMS sein.
 
Hmm.. Ich denke dann werde ich damit leben müssen.
Auf PHP FPM würde ich nur ungern umsteigen, da ich mit FCGID mitlerweile mehr Erfahrungen gesammelt habe.
 
Auf PHP FPM würde ich nur ungern umsteigen, da ich mit FCGID mitlerweile mehr Erfahrungen gesammelt habe.

Naja...ein wirklich stichhaltiges Argument ist das ja nicht ;)
FPM ist auch kein Hexenwerk und da du dich in FCGI schon eingearbeitet hast, besitzt du ja auch schon ein gewisses Grundverständnis für die Materie und eine Einarbeitung in FPM sollte da auch nicht wirklich schwer fallen.

Aber letztlich ist es auch eine Frage des Verhältnisses von Aufwand und Nutzen...und natürlich auch immer ein bissel des persönlichen Geschmacks :)
 
Spätestens mit PHP7 wirst Du Dich zwangsläufig mit FPM beschäftigen müssen, da es dann das einzige FastCGI sein wird.
 
Spätestens mit PHP7 wirst Du Dich zwangsläufig mit FPM beschäftigen müssen, da es dann das einzige FastCGI sein wird.



Wenn das so ist, werde ich mich die Tage damit mal ausführlich beschäftigen.

Edit:
Warum wird denn FCGID "abgeschafft"?
 
Last edited by a moderator:
FCGID wird nicht abgeschafft, aber PHPs CGI wird endlich um seine (instabile) FastCGI reduziert und somit eine (inkompatible) Redundanz entsorgt.
 
Back
Top