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