Multicore wird nicht effizient genutzt

B

bigfrog

New Member
Moin,
habe etwas Probleme mit der Performance auf einer Multicore-Maschine.

Erstmal die Eckdaten:
Rootserver bei Strato, 12(!) core CPU AMD Opteron(tm) Processor 4180, 16GB RAM, 2X1TB im RAID, nur / und swap Part. genug Platz frei.
Ubuntu 10.04.2 LTS Server (64bit) mit Plesk, auf dem neuesten Stand. Wird haupts. genutzt als "LAMP" Server mit Joomla! und Magento für mehrere Seiten und Kunden.
Apache 2.2.14-5ubuntu8, PHP 5.3.2-1ubuntu4, Mysql 5.1.41-3ubuntu12.10

So, jetzt zum Problem:
In der "Rush hour" bei vielen Requests steigt die CPU-Auslastung von core0 oftmals über die 100%, und dann werden die Seiten spürbar langsamer. Es ist der Apache, der diese Last verursacht. Die anderen cores langweilen sich dabei, core1 geht vielleicht mal an die 50% dann, und die Rechtlichen krebsen im einstelligen Bereich rum. Im Tagesdurchschnitt über alle cores liegt die Auslastung bei 3% bis 8%.

Wie krieg ich eine bessere Effizienz hin bzw. wo könnte das Problem liegen?

Ich weiss, dass ich am Apache selber auch noch ne Menge tweaken kann, aber es geht mir jetzt um die cores, dass die effizient genutzt werden.

Gruß
 
Gib mal die Apache CPU affinity:
Code: 
taskset -p `cat /var/run/apache2.pid`
(Falls notwendig, sched-utils installieren)

Ausserdem bitte ein Screenshot von atop in einer ruhigen Zeit und wenn Apache dieses Benehmen zutage legt.
 
Hm, ich hab jetzt rausgekriegt, dass das immer EIN EINZIGER Prozess den core auslastet, von nem Magento Shop, da war noch Optimierung möglich, jetzt ist es besser, und der shop läuft nicht mehr so hungrig. Der eine Prozess liess die Auslastung auf dem core auf 100% gehen für Sekunden

Ein Apache Prozess scheint sich nicht zu verteilen sondern arbeitet solange bis er fertig ist auf dem core.

Das mit der Virtualisierung ist eine Überlegung wert.

pid 12943's current affinity mask: fff

Da der shop jetzt besser läuft, hab ich keinen shot vom atop zur Lastzeit (toi toi toi), und spar mit jetzt auch den "normalen". Hoffentlich bleibts erstmal so.

Danke und Gruß
 
Abhängig vom eingesetzten MPM, der Methode der Einbindung von PHP im Webserver usw. läßt sich da vermutlich auch noch einiges optimieren. Allerdings weiß ich nicht, wie Plesk mit einer Änderung der MPM klar kommt.
 
Ein Apache Prozess scheint sich nicht zu verteilen sondern arbeitet solange bis er fertig ist auf dem core.
Click to expand...
Apache hat je nach MPM paar Prozesse mit vielen Threads oder viele Prozesse mit jeweils einem Thread.

Falls _ein_ Prozess deine CPU voll auslastet kann man davon ausgehen dass es ein einziger Webseitenbesuch ist der die Last verursacht, einen einzelnen Thread kann der Kernel natuerlich nicht auf mehrere Prozessoren verteilen; herumhuepfen hat auch keinen Sinn da dann der Core-interne Cache nutzlos ist.

Da du aber schreibst dass es _immer_ CPU0 ist, solltest du dem nachgehen und mit einem Apache-Benchmark (zB ab) testen ob er sauber alle Cores verwendet.
Zumindest laut der cpuaffinity-Maske sollte er es tun.
 
bigfrog said:
Ein Apache Prozess scheint sich nicht zu verteilen sondern arbeitet solange bis er fertig ist auf dem core.
Click to expand...

Naja, selbst wenn du den über andere MPMs auf mehrere Kerne verteilst wird trotzdem eine Anfrage immer nur von einem Kern (zu einem Zeitpunkt) beantwortet. Weil der Code vom PHP Skript selbst nur einem Thread entspricht (und PHP auf Linux nicht Thread-Safe ist, aber das ist ein anderes Thema...).
Das ist aber eigentlich nicht unbedingt schlecht weil Anfragen ja - zumindest normalerweise - schnell abgearbeitet werden und somit ein aufteilen auf mehrere Kerne nur unnötig last verursachen würde.

bigfrog said:
Das mit der Virtualisierung ist eine Überlegung wert.
Click to expand...

Je nach dem wie viele Besucher du hast wäre es vllt. eine gute Idee, aber der Aufwand dafür ist halt enorm - vor allem weil du dann auch deine Anwendung anpassen musst, so das Session-Daten nicht mehr auf dem Webserver gespeichert werden. Und du wirst damit 1 Anfrage trotzdem nicht auf mehr als einem Kern aufteilen können.

danton said:
Abhängig vom eingesetzten MPM, der Methode der Einbindung von PHP im Webserver usw. läßt sich da vermutlich auch noch einiges optimieren. Allerdings weiß ich nicht, wie Plesk mit einer Änderung der MPM klar kommt.
Click to expand...

Eine Auslagerung von PHP aus den Apache Prozessen führt aber halt auch zu höherer Antwortzeit (zumindest so lange genug Ressourcen da wären für den Betrieb mit mod_php). Und letztendlich läuft das PHP Skript, das den Großteil der Laufzeit/Auslastung ausmacht, damit dann ja trotzdem nur auf einem Kern .. auch wenn insgesamt rein formal natürlich 2 Prozesse (Apache und PHP Prozess) mit einer Anfrage beschäftigt sind.

Und das mit den MPMs im Falle von PHP ist auch so ne Sache.. je nach Distro lässt einen der Paketmanager gleich gar nicht was anderes auswählen außer den Prefork-MPM, wenn man mod_php will.


Die eigentliche Lösung wäre je nach dem was das Last-verursachende PHP Skript macht zu schauen ob sich die Informationen nicht im vorhinein berechnen lassen, so dass sie bei einer Anfrage nur mehr noch gelesen und nicht mehr berechnet werden müssen.
 
Last edited by a moderator:
Ich meinte eigentlich eher, dass für unterschiedliche Seiten / Benutzer / Zwecke verschiedene virtuelle Maschinen eingesetzt werden. Setzt natürlich mehrere IP Adressen und idealerweise "bridged Mode" Möglichkeit beim Provider voraus.
 
Nein, es ist nicht immer genau core0, der im Fall des Falles belastet wird, es kann auch mal ein Anderer sein. Insoweit habe ich mich im 1. Post falsch ausgedrückt. Sorry dafür.

MPM ist prefork, ich will nicht riskieren, dass uns das PHP die Grätsche macht. Ubuntu will beim Umstellen auf worker PHP5 ENTFERNEN! Ich müsste dann viel händisch nacharbeiten mit zweifelhaftem Erfolg.

Hier laufen fast alle Seiten mit PHP. (Ausser meine Eigene, die ist schön statisch :cool: )

Ich hab dasselbe Problem (Vollast auf einem core) jetzt auch auf einem anderen Server beobachtet, ein 4core. Dort konnte ich als Übeltäter ein Joomla-Backend ausmachen, im Speziellen einen Gallery-editor (Joomla plugin/modul). Da gibts bestimmt noch andere Kandidaten, ich werd jetzt ein Auge auf die "Fresser" haben und sehen ob ich noch mehr identifiziere.

Auf dem großen Server ist der Hauptschuldige ja jetzt entlarvt und gebändigt, von daher ist das Thema nicht mehr so dringend.

<zynismusmode>
PHP ist immer Schuld!
</zynismusmode>
 
Last edited by a moderator:
Ubuntu will beim Umstellen auf worker PHP5 ENTFERNEN!
Click to expand...
PHP -und zumal die Extensions- ist nicht wirklich threadsafe auch wenn es entsprechende Binaries gibt. mpm_worker ist also nur geeignet wenn PHP als cgi/fastcgi oder FPM laeuft, aber nicht fuer mod_php.

Dort konnte ich als Übeltäter ein Joomla-Backend ausmachen, im Speziellen einen Gallery-editor (Joomla plugin/modul).
Click to expand...
Solche Plugins verursachen in aller Regel durch den immensen CPU-Aufwand beim Berechnen von Thumbnails und Co solche Lastspitzen. Dagegen vorgehen kannst du hoechstens mit mod_cgroup, allerdings kenne ich keinen fertigen Kernel der den notwendigen CFS Hardlimit Patch fuer Cgroup (erkennbar an cpu.shares) mitbringt.
Alternativ gibt es fuer RedHat noch das recht teure CloudLinux welches ebenfalls ein aehnliches Konzept (afaik in Form eines Userland-Schedulers) mitbringt.
 
Naja, sofern das ganze aufs Backend beschränkt ist lohnt sich ein weiterer Aufwand deswegen denke ich mal nicht. Die Besucher bekommen davon ja vermutlich nur recht wenig zu spüren, wenn überhaupt. Sind ja schließlich noch 11 bzw. 3 weitere CPUs da.

Einzig vllt. die IO wird ein Problem .. was bei den Mengen an RAM aber durchaus auch egal sein könnte. Und wenn nicht, dann wäre wohl die einfachste Lösung Apache/Joomla eine eigene HDD zu spendieren, so dass es sich aufs Restsystem nicht auswirkt.

bigfrog said:
<zynismusmode>
PHP ist immer Schuld!
</zynismusmode>
Click to expand...

PHP ist in manchen Sachen sehr langsam, ja, aber das ist nicht das Kernproblem hier. Vielmehr ist das Problem das man PHP-Webseiten für Rechenintensive Arbeiten "Missbraucht".
Diese Tätigkeiten müsste man eigentlich aus der Web-Anwendung in ein eigenständiges Programm auslagern .. aber das sind dann halt Spezialanfertigungen und entsprechend teuer.
 
You must log in or register to reply here.
Back
Top