Mailinglisten-Archive |
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