PHP & Dualcore

[liquidbeats]

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]

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]

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]

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

Natuerlich, aber darum geht es hier ja nicht.

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]

Hallo!

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]

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]

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]

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]

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.

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.

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]

2.6.19.2

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

Ich sehe den Wald vor lauter Bäumen nicht.

Wie gesagt, viele viele Optionen.

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.

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.

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.