phpbar.de logo

Mailinglisten-Archive

[php] Argh!

[php] Argh!

Kristian =?iso-8859-1?Q?K=F6hntopp?= kk_(at)_netuse.de
Wed, 21 Jul 1999 11:56:38 +0200


Norbert Pfeiffer wrote:
> MaxClients-Werte kann man an verschiedenen Stellen eintragen.

Einen Parameter habe ich eben vergessen: MaxRequestsPerChild. Dieser
Parameter ist zusammen mit der Konstruktion von Apache entscheidend
für die Betriebsstabilität des Gesamtsystems bei Anwesenheit von
fehlerhaftem Code. Er legt fest, nach wievielen bearbeiteten Requests
sich ein Slave ins Schwer stürzt und sinnlos beendet. Setzt man den
Wert auf 0, läuft der Slave ewig, es sei denn, der Master senst ihn
wegen MaxSpareServers um.

Apache ist wie gesagt eine Serverfarm aus getrennten Prozessen. Das
bedeutet, daß die einzelnen Komponenten von Apache in getrennten
Adreßräumen laufen und sich gegenseitig nicht beeinflussen können.
CGI-Programme werden von diesen Slaves wieder als Unterprozesse
gestartet und können daher den Slave, der ihren Request bearbeitet
auch nicht beeinflussen.

Angenommen, Du hast einen CGI PHP Interpreter, der schlecht ist
(3.0.9?) und Amok läuft. Dieser PHP Interpreter kann Dir wegcoren
oder sonstwie Unsinn machen. Das stört den Slave, der den Interpreter
gestartet hat, wenig, weil es sich um einen fremden Prozeß handelt.
Cored der Amokläufer nicht, dann kriegen ihn RLIMIT_CPU oder RLIMIT_RSS
oder RLIMIT_STACK oder andere Limits und holen ihn irgendwann mit
einen Ressource Limit Exceeded runter. Die anderen Slaves der Serverfarm
juckt das nicht - fremde Requests werden also weiter sinnvoll bearbeitet.
Den Slave, der das schlechte PHP hochgezogen hat, juckt das nur in
dem Rahmen, daß er halt auf die Ergebnisse seines CGI wartet und
daß dieses sicher irgendwann terminiert (und sei es mit einem LIMIT).

Angenommen, Du hast einen mod_php Interpreter der schlecht ist.
Dann rennt das mod_php als Bestandteil eines Slaves im Adreßraum
dieses Slaves. Fehler im PHP reißen Dir dann den entsprechenden
Slaveprozeß weg. Der Master merkt das und ersetzt den fehlenden
Slave im Rahmen der MinSpareClients, MaxSpareClients und MaxClients-
Regeln. Angenommen, der mod_php cored nicht, sondern hat ein
Speicherleck, dann schlagen entweder die Ressource Limits zu
oder der Speicher wird freigegeben, wenn sich der Slave nach
MaxRequestsPerChild ins Schwert stürzt (Ich habe es bei mir
auf 300 stehen, 0 geht auch, wenn alle Module im Apache gut sind).
Für den Master ist das auch nur ein Slave, der ihm weggeflogen
ist und er forkt nach.

In jedem Fall tut der Master gar nichts mit seinen Modules,
d.h. schlechte Module tun dem Master nicht weh, weil er sie
nicht aufruft. Stattdessen kontrolliert der Master nur den
Zustand der Farm und sorgt für eine angemessene Population
von Slaveprozessen, die Requests wegschaffen. Da der
Master in einem eigenen Adreßraum läuft, können ihm defekte
Slaves nicht schaden. Damit sinkt die Leistung von Apache
in Anwesenheit von schlechten Modulen zwar, aber der Server
läuft ohne Ausfall weiter.


Man vergleiche dies mit dem Konzept des IIS, das wesentlich
mehr auf schnelle Prozeßwechsel, Vermeidung von Kontextwechseln,
Möglichkeit der IPC ausgelegt ist, aber andererseits durch
Verlagerung von Serveteilen in den Kern, Ablaufenlassen von
Serverthreads in einem gemeinsamen Adreßraum und andere Optimierungen
viele Stabilitätselemente vermissen läßt. Ein Amokläufer in
einem IIS reißt Dir entweder den gesamten IIS-Prozeß weg
(Ausnahmen können z.B. für ASP konfiguriert werden) oder kann
Dir sogar die Karre bluescreenen. Dafür ist der IIS konzeptuell
und in real Life deutlich schneller als der Apache, wenn man
nur well-behaved Komponenten einsetzt.

In real life ist die Serverleistung allerdings selten CPU-bound,
sondern meistens pipe-bound (Kabel sind halt teuer) und daher
ist das Apache-Konzept meiner persönlichen Erfahrung nach die
bessere Wahl (Sonst legt man eben noch mal 50 MHz und einige
MB RAM nach). Eine 2 MBit/34 MBit kriegt man mit einem
Xeon und Apache jedenfalls leicht saturiert...

Kristian

-- 
Kristian Köhntopp, NetUSE Kommunikationstechnologie GmbH
Siemenswall, D-24107 Kiel, Germany, +49 431 386 436 00
Using PHP3? See our web development library at
http://phplib.shonline.de/ (GPL)


php::bar PHP Wiki   -   Listenarchive