# PHP & Dualcore



## liquidbeats (1. Februar 2007)

Guten Morgen,

weis einer ob PHP mit Dualcore etwas anfangen kann? Sprich ob PHP auch beide Physikalisch zur Verfügung stehenden Kerne nutzt?


Danke

Grüße


----------



## Dennis Wronka (1. Februar 2007)

Das wird, wenn ueberhaupt von was anderem als der CPU, wohl mehr vom Betriebssystem abhaengig sein als von PHP selbst. Ich hab z.B. noch keine DualCore-Version von MS Office gesehen.


----------



## liquidbeats (1. Februar 2007)

MS Office is eh Mist. Openofficce ist doch schonmal Besser! 

Also es geht um Suse Linux 10+, Apache 2

Würde dort ein Dualcore sinn machen?

Grüße


----------



## Dennis Wronka (1. Februar 2007)

liquidbeats hat gesagt.:


> MS Office is eh Mist. Openofficce ist doch schonmal Besser!


Natuerlich, aber darum geht es hier ja nicht.



liquidbeats hat gesagt.:


> Also es geht um Suse Linux 10+, Apache 2
> 
> Würde dort ein Dualcore sinn machen?


Ich denke schon.
Wenn ich mich recht erinnere wird eine DualCore-CPU vom System mehr oder weniger wie ein Dual-CPU-System gehandhabt.
Ich kann mich auch grad nicht erinnern im Kernel mal eine Option gesehen zu haben die speziell auf DualCore ausgelegt war. Obwohl ich gestehen muss, dass ich, mangels Notwendigkeit, nie danach geguckt hab.


----------



## Dr Dau (1. Februar 2007)

Hallo!


Dennis Wronka hat gesagt.:


> Ich kann mich auch grad nicht erinnern im Kernel mal eine Option gesehen zu haben die speziell auf DualCore ausgelegt war.


Es gibt aber den Punkt "Symetric multi-processing Support" mit der Option "Maximum numbers of CPUs (2-32)".
Von DualCore steht da aber nichts.

Testen kann ich es aber nicht (mangels 2. CPU bzw. mangels DualCore).
Aber ich denke dass der Punkt aktiviert sein muss.

Gruss Dr Dau


----------



## liquidbeats (1. Februar 2007)

Dr Dau hat gesagt.:


> Es gibt aber den Punkt "Symetric multi-processing Support" mit der Option "Maximum numbers of CPUs (2-32)".
> Von DualCore steht da aber nichts.


Das bezieht sich jetzt aber nicht auf PHP oder? 
Von Kernel usw. habe ich null Ahnung, und lass lieber die finger davon =)

Grüße


----------



## Dr Dau (1. Februar 2007)

Bezieht sich auf den Kernel. 
An dem bin ich grad zugange..... bis vor ein paar Tagen habe ich mich auch noch nie mit dem kompilieren befasst..... aber ich mache Fortschritte (siehe hier), obwohl ich praktisch kein Englisch kann. 
Dauert dann halt alles nur ein wenig länger.


----------



## Dennis Wronka (1. Februar 2007)

Ich hab grad mal in die Config meines Kernels (2.6.19.1, also schon recht aktuell) geschaut und konnte dort, nach Aktivierung der SMP-Unterstuetzung nun auch einen Punkt zum Thema Multi-Core und auch Hyperthreading finden.
Ich war dann auch gleich mal so frei einen Screenshot zu machen. 

Allgemein zum Thema Kernel kompilieren kann ich nur eines sagen: Es ist nicht so gefaehrlich wie man vielleicht meinen mag, vor allem nicht wenn man den aktuell laufenden Kernel nicht gleich durch den selbstgebackenen ersetzt sondern diesen als zusaetzliche Option in den Bootmanager setzt. So hat man dann immer noch die Moeglichkeit den alten, lauffaehigen Kernel zu booten.
Die Konfig ist natuerlich sehr umfangreich, aber das liegt eben an der Masse der unterstuetzten Hardware. Um den Kernel richtig zu konfigurieren gehoert also etwas Wissen ueber die eigene Hardware und/oder der Einsatz von Programmen wie lspci und lsusb dazu, aber es ist wirklich kein Hexenwerk. Und im Grunde kann man auch theoretisch lediglich den richtigen Prozessor auswaehlen und den ganzen Rest (also wirklich alles) als Module kompilieren lassen, diese sollten dann beim Start des Systems automatisch geladen werden. So in der Art mach ich das bei meiner LiveCD, der Kernel dort hat auch einen guten Haufen Treiber als Module dabei und die fuer die Hardware passenden werden eben beim Systemstart geladen.


----------



## Dr Dau (1. Februar 2007)

Dennis Wronka hat gesagt.:


> Ich hab grad mal in die Config meines Kernels (2.6.19.1, also schon recht aktuell) geschaut und konnte dort, nach Aktivierung der SMP-Unterstuetzung nun auch einen Punkt zum Thema Multi-Core und auch Hyperthreading finden.


2.6.19.2 
Aus Platzmangel habe ich im moment aber die Sourcen wieder gelöscht.
Daher konnte ich nur beim 2.4.26-1 nachgucken.





Dennis Wronka hat gesagt.:


> Allgemein zum Thema Kernel kompilieren kann ich nur eines sagen: Es ist nicht so gefaehrlich wie man vielleicht meinen mag, vor allem nicht wenn man den aktuell laufenden Kernel nicht gleich durch den selbstgebackenen ersetzt sondern diesen als zusaetzliche Option in den Bootmanager setzt. So hat man dann immer noch die Moeglichkeit den alten, lauffaehigen Kernel zu booten.


Kann ich nur bestätigen. 


Dennis Wronka hat gesagt.:


> Die Konfig ist natuerlich sehr umfangreich, aber das liegt eben an der Masse der unterstuetzten Hardware. Um den Kernel richtig zu konfigurieren gehoert also etwas Wissen ueber die eigene Hardware und/oder der Einsatz von Programmen wie lspci und lsusb dazu, aber es ist wirklich kein Hexenwerk.


Ich sehe den Wald vor lauter Bäumen nicht. 
Es gibt aber auch die Möglichkeit die aktuelle Kernel Konfiguration zu sichern (make oldconfig)..... und diese bei "make menuconfig" (siehe Dennis sein Anhang) manuell zu laden (Load an Alternate Configuration File).
Sollte aber eigentlich auch bei "make config" machbar sein..... wobei ich persönlich "make menuconfig" wesentlich komfortabler finde (gerade für Anfänger).
Mit viel googeln/lesen und probieren kommt man dann aber auch Stück für Stück weiter (da lasse ich mich nicht so schnell klein kriegen  ).

Und wenn man, wie Dennis schon sagt, den neuen Kernel zusätzlich einbindet und den Originalen nicht einfach überschreibt, dann kann nichts passieren.
Selbst bei einem "kernel panic" hätte man dann immernoch die Möglichkeit Reset zu drücken und beim nächsten Bootvorgang den originalen Kernel auszuwählen.
Ich habe mittlerweile 4 Kernel (zusätzlich zum Originalen) eingebunden.


----------



## Dennis Wronka (1. Februar 2007)

Dr Dau hat gesagt.:


> 2.6.19.2


Ja, mir ist bekannt, dass ich ausnahmsweise mal nicht den aktuellsten Kernel laufen habe. 


Dr Dau hat gesagt.:


> Ich sehe den Wald vor lauter Bäumen nicht.


Wie gesagt, viele viele Optionen. 


Dr Dau hat gesagt.:


> Es gibt aber auch die Möglichkeit die aktuelle Kernel Konfiguration zu sichern (make oldconfig)..... und diese bei "make menuconfig" (siehe Dennis sein Anhang) manuell zu laden (Load an Alternate Configuration File).


Das ist nicht der einzige Weg. Man kann die Datei auch aus dem Config-Interface exportieren oder aber auch die Datei .config aus dem Kernel-Verzeichnis nutzen. Das ist naemlich die die auch beim kompilieren genutzt wird. Wenn man seine gesicherte Datei also gleich unter dem Namen ablegt kann man gleich mit make loslegen und braucht theoretisch nicht mehr in die Config, was ich aber trotzdem empfehle, einfach nur um zu sehen ob es was neues Interessantes gibt oder sich was gravierendes geaendert hat. Beides ist eher selten der Fall, aber eben moeglich.


Dr Dau hat gesagt.:


> Sollte aber eigentlich auch bei "make config" machbar sein..... wobei ich persönlich "make menuconfig" wesentlich komfortabler finde (gerade für Anfänger).


Nicht nur fuer Anfaenger. Ich arbeite seit 1999 mit Linux und die ganze Zeit mit make menuconfig. make config ist einfach unschoen und nicht mehr zeitgemaess. Ausserdem ist ncurses im Grunde eh Teil jedes Systems und somit wohl keine Huerde.
make xconfig (die QT-Version) oder make gconfig (die GTK-Version) hingegen mag ich nicht, da find ich make menuconfig irgendwie besser.



Dr Dau hat gesagt.:


> Und wenn man, wie Dennis schon sagt, den neuen Kernel zusätzlich einbindet und den Originalen nicht einfach überschreibt, dann kann nichts passieren.
> Selbst bei einem "kernel panic" hätte man dann immernoch die Möglichkeit Reset zu drücken und beim nächsten Bootvorgang den originalen Kernel auszuwählen.
> Ich habe mittlerweile 4 Kernel (zusätzlich zum Originalen) eingebunden.


Mittlerweile kann man im Grunde sogar auf zusaetzliche Eintraege im Bootmanager verzichten, und zwar dank kexec. Damit laesst sich der neue Kernel vorladen und dann mal eben schnell booten. Ich find das ungemein praktisch wenn mal meinen Kernel oefter am Tag baue. Geht was schief rebootet man das System normal oder per Reset und startet dann den gewohnten Kernel.
Damit kexec genutzt werden kann ist es aber noetig eine Kernel-Option zu aktivieren.

Wie das alles geht steht im verlinkten Tutorial.


----------



## Grimreaper (1. Februar 2007)

Die eigentliche Frage scheint unbeantwortet geblieben: Unterstuetzt PHP dualcore/multicore? Ich weiss nicht genau wie's ist wenn du PHP als Apache-modul einrichtest, aber sonst wird ja jedes mal der php interpreter gestartet (korrigiert mich wenn ich falsch lieg). Sollte das OS den dualcore korrent erkennen werden die php prozesse also auf die cores verteilt und PHP profitiert. Das gleiche gilt uebrigens auch fuer MS-Office


----------



## Dr Dau (2. Februar 2007)

So lange der Kernel nicht dualfähig ist, wird er auch nur die "halbe CPU" nutzen.
Folglich können Anwendungen auch nur die "halbe CPU" nutzen.
Erste Anlaufstelle ist also der Kernel..... und der muss von Haus aus nicht zwangsweise auf mehrere CPU's ausgelegt (kompiliert) sein.
Ich weiss nicht in wiefer der Kernel zwischen mehreren CPU Kernen und mehreren echten CPU's unterscheidet, aber ein aktueller Kernel währe hier sicherlich angebrachter.
Ich denke auch nicht dass der Kernel in beiden Kernen sein "Unwesen" treibt, sondern selbst nur in einem Kern läuft und lediglich den Anwendungen sagt in welchem Kern sie laufen soll.
PHP als Modul wird das System also wahrscheinlich eher ausbremsen (da ja von Apache abhängig).
PHP als CGI währe wieder eine eigenständige Anwendung..... der Kernel könnte also zu Apache sagen "Du läufst jetzt in Kern 1" und zu PHP "Du läufst jetzt in Kern 2" (je nach "Auslastung" der Kerne).

Eine konkrete Aussage scheint es wohl nicht zu geben.
Warum eigentlich nicht?
DualCore gibt es doch eigentlich schon lange genug, um Ausagen aus dem "Praxisalltag" bekommen zu können.



Dennis Wronka hat gesagt.:


> Ausserdem ist ncurses im Grunde eh Teil jedes Systems und somit wohl keine Huerde.


Ich musste ncurses (wie so vieles andere auch) erst nachinstallieren.


----------



## Dennis Wronka (2. Februar 2007)

Grimreaper hat gesagt.:


> Die eigentliche Frage scheint unbeantwortet geblieben: Unterstuetzt PHP dualcore/multicore? Ich weiss nicht genau wie's ist wenn du PHP als Apache-modul einrichtest, aber sonst wird ja jedes mal der php interpreter gestartet (korrigiert mich wenn ich falsch lieg). Sollte das OS den dualcore korrent erkennen werden die php prozesse also auf die cores verteilt und PHP profitiert. Das gleiche gilt uebrigens auch fuer MS-Office


Im Grunde hab ich dies ja bereits in meinem ersten Post angesprochen. 


Dennis Wronka hat gesagt.:


> Das wird, wenn ueberhaupt von was anderem als der CPU, wohl mehr vom Betriebssystem abhaengig sein als von PHP selbst. Ich hab z.B. noch keine DualCore-Version von MS Office gesehen.





Dr Dau hat gesagt.:


> PHP als Modul wird das System also wahrscheinlich eher ausbremsen (da ja von Apache abhängig).
> PHP als CGI währe wieder eine eigenständige Anwendung..... der Kernel könnte also zu Apache sagen "Du läufst jetzt in Kern 1" und zu PHP "Du läufst jetzt in Kern 2" (je nach "Auslastung" der Kerne).


Hier waere es interessant ob nur verschiedene Prozesse oder auch verschiedene Threads auf die verschiedenen CPUs/Kerne verteilt werden koennen. Je nach Worker-Modul (seit Apache2 gibt es da ja verschiedene, welche sich fuer unterschiedliche Situationen eignen) werden ja bereits beim Start eine Reihe von Apache-Prozessen oder -Threads angelegt, in denen dann ja auch das PHP-Modul beheimatet ist. In jedem Fall wuerde ich weiterhin auf PHP als Modul und nicht als CGI setzen.
Es ist hier halt nur ratsam sich dann damit auseinander zu setzen welches der Worker-Module fuer den Einsatz auf Multi-CPU- oder Multi-Core-Systemen am besten geeignet ist. Und dazu sollte sich durchaus was im Internet finden lassen.


Dr Dau hat gesagt.:


> Ich musste ncurses (wie so vieles andere auch) erst nachinstallieren.


Ich koennte mir vorstellen, dass ncurses (also die Libraries) bereits da waren, Du aber noch die Header (also das Dev-Paket, wie es bei vielen Distros so schoen heisst) brauchtest.


----------



## Matthias Reitinger (2. Februar 2007)

Hallo,



Dennis Wronka hat gesagt.:


> Hier waere es interessant ob nur verschiedene Prozesse oder auch verschiedene Threads auf die verschiedenen CPUs/Kerne verteilt werden koennen.


Es ist zumindest definitiv möglich und auch so gedacht, dass die Threads eines einzigen Prozesses auf verschiedene Kerne (oder physikalische CPUs) verteilt werden können. Ob der (aktuelle) Linux-Kernel das unterstützt, weiß ich leider nicht. Ich gehe aber stark davon aus.

Grüße,
Matthias


----------



## Dennis Wronka (2. Februar 2007)

Vielleicht find ich am Wochenende was Zeit und Motivation was durch die Kernel-Doku zu wandern und auch was ueber die Worker vom Apache zu lesen.
Will ja dieses Jahr auf AMD64 X2 gehen (dann mit 2GB RAM) und da wird das dann auch relevant sowas.


----------



## liquidbeats (13. Februar 2007)

Hallo Dennis Wronka,
und gabs etwas Neues?

Grüße


----------

