Allgemeine Direktiven der Apache-MPMs

AcceptMutex-Direktive

Die Direktive AcceptMutex bestimmt die Methode, die der Apache zur Serialisierung mehrerer Kindprozesse verwendet, welche Anfragen an Netzwerk-Sockets entgegennehmen. Vor Apache 2.0 war diese Methode nur zur Kompilierungszeit einstellbar. Die optimale Methode ist sehr stark von der Architektur und Plattform abhÄngig. Lesen Sie bitte Perfomance-Hinweise fÝr weitere Details.

Wenn die Direktive auf Default eingestellt ist, dann wird die zur Kompilierungszeit gewÄhlte Voreinstellung verwendet. Weitere mÆgliche Methoden sind unten angegeben. Beachten Sie, dass nicht alle Methoden auf allen Plattformen verfÝgbar sind. Wird eine Methode angegeben, die nicht verfÝgbar ist, dann wird eine Nachricht in das Fehlerprotokoll geschrieben, welche die verfÝgbaren Methoden auflistet.

flock

verwendet die Systemfunktion flock(2), um die durch die LockFile-Direktive definierte Datei zu sperren.

fcntl

verwendet die Systemfunktion fcntl(2), um die durch die LockFile-Direktive definierte Datei zu sperren.

posixsem

verwendet POSIX-kompatible Semaphore, um den Mutex zu implementieren.

pthread

verwendet gemÄú der POSIX-Thread-Spezifikation implementierte POSIX-Mutexe.

sysvsem

verwendet Semaphoren des SysV-Typs, um den Mutex zu implementieren.

Um die bei der Kompilierung gewÄhlte Voreinstellung fÝr Ihr System herauszufinden, kÆnnen Sie Ihr LogLevel auf debug setzen. Dann wird der voreingestellte AcceptMutex ins ErrorLog geschrieben.

BS2000Account-Direktive

Die Direktive BS2000Account ist nur fÝr BS2000-Hosts verfÝgbar. Sie muss dazu verwendet werden, den Account fÝr den nicht-privilegierten Apache-Server-Benutzer (der durch die Direktive User eingestellt wird) zu bestimmen. Dies wird vom BS2000-POSIX-Subsystem benÆtigt (um die zugrundeliegende BS2000-Anwendungsumgebung mittels eines Sub-LOGONs zu wechseln), um zu verhindern, dass CGI-Skripte auf Ressourcen des privilegierten Accounts zugreifen, der den Server gestartet hat, Ýblicherweise SYSROOT.

Siehe auch

• Apache-EBCDIC-Portierung

CoreDumpDirectory-Direktive

Dies beeinflusst das Verzeichnis, in welches der Apache zu wechseln versucht, bevor er einen Hauptspeicherauszug (Anm.d.ý.: einen so genannten Core-Dump) erstellt. Die Voreinstellung ist das ServerRoot-Verzeichnis. Da dieses jedoch nicht fÝr den Benutzer beschreibbar sein soll, unter dem der Server lÄuft, werden normalerweise keine HauptspeicherauszÝge geschrieben. Wenn Sie zum Debuggen einen Hauptspeicherauszug haben mÆchten, kÆnnen Sie ihn mit dieser Direktive an einem anderen Ort ablegen lassen.

EnableExceptionHook-Direktive

Diese Direktive ist aus SicherheitsgrÝnden nur verfÝgbar, wenn der Server mit der Option --enable-exception-hook konfiguriert wurde. Sie aktiviert einen Hook, der es externen Modulen erlaubt, sich dort einzuhÄngen und nach dem Absturz eines Kindprozesses noch Aktionen durchzufÝhren.

Es existieren bereits zwei Module, mod_whatkilledus und mod_backtrace, welche diesen Hook verwenden. Weitere Informationen hierzu finden Sie auf Jeff Trawicks EnableExceptionHook-Seite.

Group-Direktive

Die Direktive Group bestimmt die Benutzergruppe, unter welcher der Server Anfragen beantwortet. Um diese Direktive zu verwenden, muss der Server als root gestartet werden. Wenn Sie den Server unter einem nicht-root-Benutzer starten, wird er nicht zur angegebenen Gruppe wechseln kÆnnen und statt dessen weiter mit der Gruppe des ursprÝnglichen Benutzers laufen. Unix-Gruppe kann sein:

Ein Gruppenname

Verweist auf die durch den Namen angegebene Gruppe.

# gefolgt von einer Gruppennummer.

Verweist auf die durch ihre Nummer angegebene Gruppe.

Es wird empfohlen, dass Sie eine neue Gruppe speziell zum Betrieb des Servers erstellen. Einige Administratoren verwenden den Benutzer nobody. Dies ist jedoch nicht immer mÆglich oder gewÝnscht.

Wichtiger Hinweis: Die Verwendung der Direktive innerhalb von <VirtualHost> wird nicht lÄnger unterstÝtzt. Benutzen Sie SuexecUserGroup um Ihren Server fÝr suexec einzurichten.

Listen-Direktive

Die Direktive Listen weist den Apache an, nur an den angegebenen IP-Adressen oder Ports zu lauschen. StandardmÄúig antwortet er auf alle Anfragen an allen IP-Interfaces. Listen ist nun eine notwendige Anweisung. Wenn sie nicht in der Konfigurationsdatei enthalten ist, wird der Server-Start fehlschlagen. Dies ist eine änderung gegenÝber frÝheren Versionen des Apache.

Die Direktive Listen weist den Server an, ankommende Anfragen am angegebenen Port oder der Kombination aus Adresse und Port entgegenzunehmen. Wenn nur eine Portnummer angegeben ist, dann lauscht der Server am angegebenen Port an allen Interfaces. Wenn sowohl eine IP-Adresse als auch ein Port angegeben sind, dann lauscht der Server am angegeben Port und Interface.

Es kÆnnen mehrere Listen-Anweisungen verwendet werden, um eine Reihe von Adressen und Port anzugeben, an denen gelauscht werden soll. Der Server antwortet auf Anfragen von jedem der aufgefÝhrten Adressen und Ports.

Um beispielsweise den Server Verbindungen an den beiden Ports 80 und 8000 annehmen zu lassen, verwenden Sie:

Um den Server Verbindungen an zwei angegebenen Interfaces und Ports annehmen zu lassen, verwenden Sie:

IPv6-Adressen mÝssen wie in dem folgenden Beispiel in eckige Klammern eingeschlossen werden:

Siehe auch

• DNS-Probleme
• Bestimmen, welche Adressen und Ports der Apache verwendet

ListenBackLog-Direktive

Die maximale LÄnge der Warteschlange schwebender Verbindungen. ýblicherweise ist keine Feineinstellung notwendig oder sinnvoll, auf einigen System kann es jedoch gewÝnscht sein, diesen Wert bei TCP-SYN-Angriffen zu erhÆhen. Beachten Sie auch die Beschreibung des backlog-Parameters der Systemfunktion listen(2).

Der Wert wird vom Betriebssystem oft auf eine niedrigere Einstellung begrenzt. Dies variiert von Betriebssystem zu Betriebssystem. Beachten Sie auch, dass viele Betriebssyteme nicht genau beachten, was fÝr backlog angegeben ist, jedoch einen Wert basierend auf der Angabe (normalerweiseweise jedoch grÆúer als diese) verwenden.

LockFile-Direktive

Die Direktive LockFile legt den Pfad zur Lock-Datei fest, die verwendet wird, wenn der Apache mit einer der AcceptMutex-Einstellungen fcntl oder flock verwendet wird. Die Anweisung sollte normalerweise bei der Voreinstellung belassen werden. Der Hauptgrund, sie zu Ändern, ist, wenn das logs-Verzeichnis auf einem per NFS-eingebundenen Laufwerk liegt, da die Lock-Datei auf einer lokalen Platte abgelegt sein muss. Die PID (Anm.d.ý.: Prozess-ID) des Hauptserverprozesses wird automatisch an den Dateinamen angehÄngt.

Siehe auch

• AcceptMutex

MaxClients-Direktive

Die Direktive MaxClients setzt die Grenze fÝr die Anzahl gleichzeitig bedienter Anfragen. Jeder Verbindungsversuch oberhalb der MaxClients-Begrenzung wird Ýblicherweise in eine Warteschlange gestellt, bis zu einer Anzahl basierend auf der ListenBacklog-Anweisung. Sobald ein Kindprozess am Ende einer anderen Anfrage freigegeben wird, wird die Verbindung bedient.

FÝr Server ohne Thread-UnterstÝtzung (z.B. prefork) wird MaxClients als maximale Anzahl der Kindprozesse verstanden, die zur Bedienung von Anfragen gestartet werden. Die Voreinstellung ist 256. Um diesen Wert zu erhÆhen, muss auch ServerLimit angehoben werden.

Bei Servern mit Thread-UnterstÝtzung und bei Hybrid-Servern (z.B. beos oder worker) begrenzt MaxClients die Gesamtzahl der Threads, die fÝr die Bedienung von Anfragen verfÝgbar sind. Die Voreinstellung fÝr beos ist 50. Bei Hybrid-MPMs ist die Voreinstellung 16 (ServerLimit) multipliziert mit dem Wert 25 (ThreadsPerChild). Um MaxClients auf einen Wert zu erhÆhen, der mehr als 16 Prozesse erfordert, mÝssen Sie daher auch ServerLimit anheben.

MaxMemFree-Direktive

Die Direktive MaxMemFree gibt die maximale Menge freier Kilobytes an, welche die Haupt-Zuteilungsroutine verwalten darf, ohne free() aufzurufen. Wenn keine Angabe gemacht wird, oder Null angegeben ist, wird dieser Wert nicht eingeschrÄnkt.

MaxRequestsPerChild-Direktive

Die Direktive MaxRequestsPerChild legt die Grenze fÝr die Anzahl von Anfragen fest, die ein einzelner Kinprozess wÄhrend seines Lebens bearbeitet. Nach MaxRequestsPerChild Anfragen stirbt der Kindprozess. Wenn MaxRequestsPerChild 0 ist, endet der Prozess niemals.

Die Begrenzung von MaxRequestsPerChild auf einen Wert ungleich Null hat zwei vorteilhafte Auswirkungen:

• sie begrenzt die Menge an Arbeitsspeicher, die ein Prozess durch (versehentliche) Speicherlecks verbrauchen kann.
• das Festlegen einer endlichen Lebensdauer von Prozessen hilft, die Anzahl von Prozessen zu reduzieren, wenn die Serverlast zurÝckgeht.

MaxSpareThreads-Direktive

Maximale Anzahl unbeschÄftigter Threads. Die verschiedenen MPMs behandeln diese Anweisung unterschiedlich.

Die Voreinstellung fÝr perchild ist MaxSpareThreads 10. Das MPM Ýberwacht die Anzahl der unbeschÄftigten Threads auf der Basis einzelner Kindprozesse. Wenn zu viele unbeschÄftigte Threads in einem Kindprozess existieren, beendet der Server Threads innerhalb dieses Kindprozesses.

Die Voreinstellung fÝr worker, leader und threadpool ist MaxSpareThreads 250. Diese MPMs behandeln Threads auf einer serverweiten Basis. Wenn zu viele unbeschÄftigte Threads im Server existieren, dann werden solange Kindprozesse beendet, bis die Anzahl der unbeschÄftigten Threads kleiner als der angegebene Wert ist.

Die Voreinstellung fÝr mpm_netware ist MaxSpareThreads 100. Da dieses MPM nur einen einzigen Prozess ausfÝhrt, ist die ZÄhlung ÝberschÝssiger Threads ebenfalls serverweit.

beos and mpmt_os2 arbeiten Ähnlich wie mpm_netware. Die Voreinstellung fÝr beos ist MaxSpareThreads 50. Die Voreinstellung fÝr mpmt_os2 ist 10.

Siehe auch

• MinSpareThreads
• StartServers

MinSpareThreads-Direktive

Minimale Anzahl unbeschÄftigter Threads, um Anfragespitzen zu bedienen. Die verschiedenen MPMs behandeln die Anweisung unterschiedlich.

perchild verwendet die Voreinstellung MinSpareThreads 5 und Ýberwacht die Anzahl der unbeschÄftigten Threads auf der Basis einzelner Kindprozesse. Wenn in einem Kindprozess nicht genÝgend unbeschÄftigte Threads vorhanden sind, erstellt der Server neue Threads innerhalb dieses Kindprozesses. Wenn Sie also NumServers auf 10 und MinSpareThreads auf einen Wert von 5 setzen, haben Sie mindestens 50 unbeschÄftigte Threads auf Ihrem System.

worker, leader und threadpool verwenden eine Voreinstellung von MinSpareThreads 75 und behandeln unbeschÄftigte Threads auf serverweiter Basis. Wenn nicht genÝgend unbeschÄftigte Threads im Server vorhanden sind, dann werden solange Kindprozesse erzeugt, bis die Anzahl unbeschÄftigter Threads grÆúer als der angegebene Wert ist.

mpm_netware verwendet die Voreinstellung MinSpareThreads 10 und verfolgt dies serverweit, da es ein Einzelprozess-MPM ist.

beos und mpmt_os2 arbeiten Ähnlich wie mpm_netware. Die Voreinstellung fÝr beos ist MinSpareThreads 1. Die Voreinstellung fÝr mpmt_os2 ist 5.

Siehe auch

• MaxSpareThreads
• StartServers

PidFile-Direktive

Die Direktive PidFile bestimmt die Datei, in welcher der Server die Prozess-ID des Daemons ablegt. Wenn der Dateiname nicht absolut angegeben wird, wird er relativ zu ServerRoot interpretiert.

Es ist oft hilfreich, dem Server ein Signal senden zu kÆnnen, damit er seine ErrorLogs und TransferLogs schlieút und dann neu Æffnet und seine Konfigurationsdateien neu einliest. Dies kann durch Senden eines SIGHUP-Signals (kill -1) an die Prozess-ID geschehen, die im PidFile eingetragen ist.

Die PidFile-Datei unterliegt den gleichen Warnungen Ýber die Ablage von Protokolldateien und Sicherheit.

ScoreBoardFile-Direktive

Apache verwendet ein Scoreboard zur Kommunikation zwischen seinen Eltern- und Kindprozessen. Einige Architekturen erfordern eine Datei zur UnterstÝtzung der Kommunikation. Wenn die Datei undefiniert bleibt, versucht der Apache zuerst, das Scoreboard im Arbeitsspeicher zu erstellen (Verwendung von anonymem Shared-Memory), und versucht bei einem Fehlschlag anschlieúend die Datei auf der Festplatte zu erstellen (Verwendung von Datei-basiertem Shared-Memory). Die Angabe dieser Direktive veranlaút den Apache stets, die Datei auf der Festplatte zu erstellen.

Datei-basiertes Shared-Memory ist fÝr Applikationen von Drittanbietern hilfreich, die direkten Zugriff auf das Scoreboard benÆtigen.

Wenn Sie eine ScoreBoardFile-Anweisung verwenden, erreichen Sie eventuell eine hÆhere Geschwindigkeit, wenn Sie die Datei auf einer RAM-Disk ablegen. Achten Sie darauf, die gleichen Warnungen wie Ýber die Ablage von Protokolldateien und Sicherheit zu beherzigen.

Siehe auch

• Apache beenden und neu starten

SendBufferSize-Direktive

Der Server setzt die GrÆúe des TCP-Puffers auf die angegebene Anzahl Bytes. Dies ist sehr hilfreich, um Voreinstellungen alter Standardbetriebssysteme fÝr Hochgeschwindigkeitsverbindungen mit hoher Latenzzeit anzuheben (d.h. 100ms oder so, wie bei Interkontinentalverbindungen).

Wird der Wert auf 0 gesetzt, dann verwendet der Server die Voreinstellung des Betriebssystems.

ServerLimit-Direktive

Bei dem MPM prefork bestimmt die Direktive den wÄhrend der Lebensdauer des Apache-Prozesses maximal einstellbaren Wert fÝr MaxClients. Beim MPM worker bestimmt die Direktive in Verbindung mit ThreadLimit den Maximalwert fÝr MaxClients fÝr die Lebensdauer des Apache-Prozesses. Jeder Versuch, diese Anweisung wÄhrend eines Neustarts zu Ändern, wird ignoriert. MaxClients kann jedoch wÄhrend eines Neustarts geÄndert werden.

Lassen Sie besondere Vorsicht bei der Verwendung dieser Direktive walten. Wenn ServerLimit auf einen Wert deutlich hÆher als notwendig gesetzt wird, wird zusÄtzliches, unbenutztes Shared-Memory belegt. Wenn sowohl ServerLimit als auch MaxClients auf Werte gesetzt werden, die grÆúer sind, als das System sie handhaben kann, dann kann der Apache mÆglicherweise nicht starten, oder das System kann instabil werden.

Verwenden Sie die Direktive bei dem MPM prefork nur, wenn Sie MaxClients auf mehr als 256 (Voreinstellung) setzen mÝssen. Setzen Sie den Wert nicht hÆher als den Wert, den Sie fÝr MaxClients angeben mÆchten.

Verwenden Sie die Direktive bei worker, leader und threadpool nur, wenn Ihre MaxClients- und ThreadsPerChild-Einstellungen mehr als 16 Serverprozesse (Voreinstellung) erfordern. Setzen Sie den Wert dieser Direktive nicht hÆher, als die Anzahl der Serverprozesse, die dafÝr erforderlich ist, was Sie bei MaxClients und ThreadsPerChild angeben mÆchten.

Verwenden Sie die Direktive beim MPM perchild nur, wenn Sie NumServers auf einen Wert grÆúer als 8 (Voreinstellung) setzen mÝssen.

Siehe auch

• Apache beenden und neu starten

StartServers-Direktive

Die Direktive StartServers bestimmt die Anzahl der Kindprozesse des Servers, die beim Start erstellt werden. Da die Anzahl der Prozesse abhÄngig von der Last dynamisch kontrolliert wird, besteht normalerweise wenig Grund fÝr eine änderung dieses Parameters.

Die Voreinstellung unterscheidet sich von MPM zu MPM. Bei leader, threadpool und worker ist die Voreinstellung StartServers 3. Die Voreinstellung bei prefork ist 5 und bei mpmt_os2 2.

StartThreads-Direktive

Anzahl der Threads, die beim Start erstellt werden. Da die Anzahl der Threads abhÄngig von der Last dynamisch kontrolliert wird, besteht normalerweise wenig Grund fÝr eine änderung dieses Parameters.

Die Voreinstellung fÝr perchild ist StartThreads 5. Die Direktive setzt wÄhrend des Starts die Anzahl der Threads pro Prozess.

Die Voreinstellung bei mpm_netware ist StartThreads 50. Da hier lediglich ein einzelner Prozess existiert, ist dies die Gesamtzahl der Threads, die beim Start erstellt wird, um Anfragen zu bedienen.

Die Voreinstellung fÝr beos ist StartThreads 10. Die Einstellung reflektiert ebenfalls die Gesamtzahl der Threads, die beim Start erstellt werden, um Anfragen zu bedienen.

ThreadLimit-Direktive

Die Direktive bestimmt den wÄhrend der Lebensdauer des Apache-Prozesses maximal einstellbaren Wert fÝr ThreadsPerChild. Jeder Versuch, diese Direktive wÄhrend eines Neustarts zu Ändern, wird ignoriert. ThreadsPerChild kann jedoch wÄhrend eines Neustarts modifiziert werden bis zu dem Wert dieser Anweisung.

Lassen Sie besondere Vorsicht bei der Verwendung dieser Direktive walten. Wenn ThreadLimit auf einen Wert deutlich hÆher als ThreadsPerChild gesetzt wird, wird zusÄtzliches, ungenutztes Shared-Memory belegt. Wenn sowohl ThreadLimit als auch ThreadsPerChild auf Werte gesetzt werden, die grÆúer sind, als das System sie handhaben kann, dann kann der Apache mÆglicherweise nicht starten oder das System kann instabil werden. Setzen Sie den Wert dieser Direktive nicht hÆher als Ihre grÆúte erwartete Einstellung fÝr ThreadsPerChild wÄhrend der aktuellen AusfÝhrung des Apache.

Die Voreinstellung fÝr ThreadLimit ist 1920 wenn sie zusammen mit mpm_winnt verwendet wird, und 64 bei der Verwendung mit anderen MPMs.

ThreadsPerChild-Direktive

Die Direktive legt die Anzahl der Threads fest, die mit jedem Kindprozess gestartet werden. Der Kindprozess erstellt diese Threads beim Start und erstellt spÄter keine weiteren mehr. Wenn Sie ein MPM wie mpm_winnt verwenden, wo nur ein Kindprozess existiert, dann sollte diese Angabe hoch genug sein, die gesamte Last des Servers zu bewÄltigen. Wenn Sie ein MPM wie worker verwenden, wo mehrere Kindprozesse existieren, dann sollte die Gesamtzahl der Thread groú genug sein, die Ýbliche Last auf dem Server zu bewÄltigen.

Die Voreinstellung fÝr ThreadsPerChild ist 64, wenn mpm_winnt verwendet wird, und 25 bei der Verwendung der anderen MPMs.

User-Direktive

Die Direktive User legt die Benutzerkennung fest, mit der der Server Anfragen beantwortet. Um diese Anweisung zu verwenden, muss der Server als root gestartet werden. Wenn Sie den Server unter einem nicht-root-Benutzer starten, kann er nicht zu dem minder privilegierten Benutzer wechseln und wird statt dessen weiter mit der ursprÝnglichen Benutzerkennung laufen. Wenn Sie den Server als root starten, dann ist es normal, dass der Elternprozess als root weiterlÄuft. Unix-User-ID kann sein:

Ein Benutzername

Verweist auf den durch Namen angegebenen Benutzer.

# gefolgt von einer Benutzernummer.

Verweist auf einen durch eine Nummer angegebenen Benutzer.

Der Benutzer sollte keine Rechte besitzen, die dazu fÝhren, dass er in der Lage ist, auf Dateien zuzugreifen, die nicht dafÝr bestimmt sind, fÝr die Auúenwelt sichtbar zu sein. Gleichermaúen sollte der Benutzer nicht in der Lage sein, Code auszufÝhren, der nicht fÝr HTTP-Anfragen bestimmt ist. Es wird empfohlen, einen neuen Benutzer und eine neue Gruppe speziell zur AusfÝhrung des Servers zu erstellen. Einige Administratoren verwenden den Benutzer nobody. Dies ist jedoch nicht immer wÝnschenswert, da der Benuter nobody andere Rechte auf dem System besitzen kann.

Beim MPM perchild, das dafÝr gedacht ist, virtuelle Hosts unter verschiedenen Benutzerkennungen auszufÝhren, bestimmt die Direktive User die Benutzerkennung fÝr den Hauptserver und bildet den RÝckfallwert fÝr <VirtualHost>-Abschnitte ohne eine AssignUserID-Anweisung.

Wichtiger Hinweis: Die Verwendung dieser Direktive innerhalb von <VirtualHost> wird nicht mehr unterstÝtzt. Benutzen Sie SuexecUserGroup, um Ihren Server fÝr suexec einzurichten.