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:41:57 +0200


Norbert Pfeiffer wrote:
> - Der Wert repraesentiert die maximale Anzahl gleichzeitiger Zugriffe
>   beziehungsweise Anfragen an einen Dienst/Server.

Apache ist eine Serverfarm bestehend aus einem Masterprozeß, der
als Aufseher und Scheduler wirkt und die Anfragen, die hereinkommen
an eine Reihe von Slave-Prozessen verteilt. Apache verwaltet die
Größe der Serverfarm dynamisch. Dazu startet der Master beim
Hochfahren Startservers viele Clients. 

Kommen Requests rein, versucht der Server immer mindestens 
MinSpareServers viele Slaveprozesse zu haben, die gerade 
idle sind (Wozu? Nachstarten von mehr Slaves
kostet Zeit und in der Zeit können weitere Requests kommen, also
sollte man immer ein paar idle Slaves auf Vorrat haben). Apache
vergrößert also die Serverfarm, wenn Last anliegt, also Requests
zu beantworten sind.

Nimmt man die Last wieder herunter, sind sehr viele Slaves vorhanden,
die idle herumstehen. Sind das mehr als MaxSpareServers viele, geht
der Master daher und senst überschüssige Slaves um, um die Größe der
Serverfarm anzupatzen.

Damit die Maschine nicht irgendwann out-of-memory über die linke
Tragfläche abkippt und sich in den Boden bohrt, muß man die maximale
Gesamtgröße der Serverfarm begrenzen, auf MaxClients viele
Prozesse.

Apache unter Last in tight memory situations: Angenommen MaxClients
ist ein sehr großer, quasi unendlicher Wert. Dann startet Apache bei
zunehmender Last mehr Slaves, die die Requests abfeiern. Irgendwann
ist der Speicher alle, und die Maschine geht in den Swap. In diesem
Moment wird die Bearbeitung der Requests langsamer, weil Swap Zeit 
kostet. Das bedeutet bei gleichmßig vielen Requests pro Sekunde, daß
mehr Requests parallel verarbeitet werden müssen, um Schritt zu halten.
Apache versucht also mehr Clients zu starten und treibt die Maschine
noch weiter in den Swap, dadurch wird sie noch langsamer, also versucht
Apache die Abarbeitung noch weiter zu parallelisieren.

Mit MaxClients kannst Du die Größe der Serverfarm so begrenzen, sodaß
genau dieser Effekt nicht eintritt. MaxClients soll so gesetzt werden,
daß die Maschine gerade eben den Swap nicht anfasst. Dann ist das
Tuning für die Kiste korrekt.

> - Was passiert mit 'ueberschuessigen' Requests ?

TCP Sockets haben ein Listen Backlog. Dieses Backlog
bestimmt, wieviele TCP connects unbearbeitet in der Queue für
einen Select stehen können. Wenn also alle Slaves beschäftigt
sind, dann stauen sich ListenBacklog 
(http://www.apache.org/docs/mod/core.html#listenbacklog)
Requests auf dem Socket. Dieser Vorgang ist auch in
TCP/IP Illustrated, Vol 1: The Protocols sehr schön diskutiert (http://www.amazon.de/exec/obidos/ASIN/0201633469/kristiankohntopp/,
sehr empfehlenswertes und absolut unentbehrliches Buch).

Was der Parameter für ListenBacklog bewirkt, kannst Du nur verstehen,
wenn Du "man 2 listen" für Dein OS durchgelesen hast. In Linux kann
der globale Defaultwert dafür übrigens in /proc/sys/net/ipv4/tcp_max_syn_backlog
nachgesehen werden (128).

> - Gilt dies fuer jeden einzelnen Server/Dienst: httpd, db, mail, ftp...
>   und in der Summe fuer die Maschine, oder nur in Summe.

Speicher (RAM) ist eine Ressource, die von allen Prozessen im System
geshared wird. Speichertuning muß sich also auf alle Prozesse
beziehen.

> - Hat der Herr Koehntop dazu auch einen Artikel geschrieben ?
>   Falls ja, verrate mir/uns bitte die Adresse...  :)

LAMP Performance Tuning in englischer Sprache ist in Arbeit
und wird in einigen Wochen auf Devshed einschlagen. Im Moment
habe ich jedoch einige ganz andere Sachen mit techno-politischem
Hintergrund in Arbeit ("Why Internet Content Rating and Selection
does not work"). Da müssen andere Sachen zurückstehen.

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