Auf der Maschine ist wirklich viel los!
Am 06.12.2006 um 14:58 schrieb MacGyver:
Ja - das ist mir soweit bekannt.
Das Problem ist:
RAM ist mehr als genug vorhanden - von den 4GB werden gerade mal max.
1,5 GB genutzt.
Wenn ich aber anfange MaxClients zu erhöhen, dann steigt die Load
rasant
weiter an. Zeitweise lief der Server auch mit MaxClients von
200-1000 -
allerdings bekam der Server dann auch schell und regelmäßig Loads von
60-200 - was dann dauerhaft zur Folge hat, das er sich selbst
erstickt.
Der (relativ geringe) Wert von 70 MaxClients bringt immernoch eine
Load
von bis zu 50 - das ist schon viel zu viel um gute
Request-Response-Zeiten zu bekommen - aber der Server erstickt sich
wenigstens nicht selber.
Ich wuerde sagen, die Ursache der hohen Last sind die php-skripte.
Gibt es dort vielleicht lastintensive Berechnungen oder Plattenzugriffe?
Es erklärt aber auch nicht, warum die "W" ("Sending reply") so
übermäßig
lange in allen Slots hängen bleiben - oder ?
weil die php-skripte so lange laufen. je hoeher die last, desto
laenger laufen die. Wenn du die MaxClients hochsetzt wird irgendwann
die kritische Grenze ueberschritten - der Server kommt mit der
Rechnerei oder Plattennutzung nicht mehr hinterher.
Gruss,
Richard
Jetzt - peak-time - sieht es übrigens so aus:
Server uptime: 37 minutes 22 seconds
Total accesses: 149319 - Total Traffic: 1.6 GB
CPU Usage: u1344.45 s87.59 cu.16 cs0 - 63.9% CPU load
66.6 requests/sec - 0.7 MB/second - 11.3 kB/request
70 requests currently being processed, 0 idle workers
WWWWWWCWWWWWWWWWWWWWCWWCWWWWWRWWWWWCWWWWCWWCWWWWWCWWWWWWWWWWWCWW
WCWWWW..........................................................
................................................................
[EMAIL PROTECTED] schrieb:
hi,
Quelle : http://httpd.apache.org/docs/2.0/de/mod/prefork.html
<cite>
Das MPM ist stark selbstregulierend, so dass es selten notwendig
ist, seine Konfigurationseinstellungen zu justieren. Das
Wichtigste ist, dass MaxClients gross genug ist, so viele
gleichzeitige Anfragen zu bedienen, wie Sie erwarten, aber klein
genug, um sicherzustellen, dass genug physischer Arbeitsspeicher
für alle Prozesse vorhanden ist.
</cite>
also ist 70 anscheinend zu wenig ...
greetz
h1
-----Ursprüngliche Nachricht-----
Von: MacGyver [mailto:[EMAIL PROTECTED]
Gesendet: Mittwoch, 6. Dezember 2006 14:30
An: [email protected]
Betreff: Re: AW: AW: AW: Apache hängt im Status "Sending Reply"
Serverlimit = 512
MaxClients = 70
ThreadsPerChild = ? ist gar nicht gesetzt. also Default.
Ist ThreadsPerChild für Prefork überhaupt relevant ?
Und wie könnte dieser Wert mit dem beschriebenen Problem beim
"Sending
Reply" zusammehängen ?
[EMAIL PROTECTED] schrieb:
hi mac gyver,
dazu fällt mir spontan ein :
ServerLimit >= MaxClients / ThreadsPerChild
wie siehts aus mit ThreadsPerChild ?
greetz
h1
-----Ursprüngliche Nachricht-----
Von: MacGyver [mailto:[EMAIL PROTECTED]
Gesendet: Mittwoch, 6. Dezember 2006 13:49
An: [email protected]
Betreff: Re: AW: AW: Apache hängt im Status "Sending Reply"
Naja - danach hatte ich ja gerade gefragt :)
Was ist denn relevant ?
Ich werf mal ein paar Parameter rein, die ich für relevant halte:
ServerLimit 512
Timeout 15
Prefork:
StartServers 50
MinSpareServers 10
MaxSpareServers 10
MaxClients 70
MaxRequestsPerChild 2000
HostnameLookups Off
KeepAlive Off
Server:
P4 - 3GHz - 4 GB RAM
Apache 2.0.55
Anwendung auf php - backend MySql auf dediziertem zweiten Server
eaccelerator
Last:
Server uptime: 10 hours 35 minutes 17 seconds
Total accesses: 1350840 - Total Traffic: 13.9 GB
Hoffe das ist soweit umfassend.
[EMAIL PROTECTED] schrieb:
hi,
poste doch mal die relevanten parameter aus deiner conf bitte,
damit man mal eine diskussionsgrundlage hat.
greetz
h1
-----Ursprüngliche Nachricht-----
Von: MacGyver [mailto:[EMAIL PROTECTED]
Gesendet: Mittwoch, 6. Dezember 2006 13:20
An: [email protected]
Betreff: Re: AW: Apache hängt im Status "Sending Reply"
Die Last wird vom Apachen erzeugt -
außer dem Apachen läuft auch nichts weiter auf der Maschine und Top
bestätigt, das der apache dort am stressen ist.
Was ist denn ein IDE-System ? Ich kenne "Integrated Developement
Environment" - aber zusammen mit Apache und Server-Performance
bekomme
ich das gerade nicht zusammen.
Gibt es noch Infos die ich zur Verfügung stellen könnte, die das
Problem
eingrenzen würden ?
Btw: Die Server laufen mit MaxConnections = 50 - wenn ich diesen
Wert
erhöhe steigt die Last überproportional weiter an und es wird
nur schlimmer.
Matthias Jambor schrieb:
Hallo Simon,
welcher Process ist für die Last verantwortlich? Versuche mal
mit "top" den
Verursacher zu finden.
Schönen Gruß
Matthias
_____________________________________________
Von: Marco Simon [mailto:[EMAIL PROTECTED]
Gesendet: Mittwoch, 6. Dezember 2006 03:20
An: [email protected]
Betreff: Apache hängt im Status "Sending Reply"
Hallo Liste,
ich betreue eine recht stark genutzte Webanwendung. Die
Webanwenung ist
php-basiert. Die Datenbank (mysql) liegt auf einem zweiten
Server, der
sich mit dem Webserver-Host im gleichen Netzwerk befindet. Die
Webanwendung wird praktisch ausschließlich von Internet-Clients
verwendet.
Die Apache-Version ist 2.0.55.
Der Host ist ein Pentium 4 3GHz mit 4 GB Ram.
Der Server swapt nicht, hat aber zu den Haupt-Last-Zeiten eine
Load von >20.
Und genau hier beginnt das Problem. Denn zusammen mit diesen
hohen Loads
steigen auch die Antwortzeiten sehr stark - bzw. es kommt zu
timeouts
(30 sek).
Zu diesen Zeiten fällt die Last auf den DB-Server - dort
scheint der
Flaschenhals also nicht zu liegen.
Auffällig ist die Tatsache, das laut /server-status offenbar
der Apache
bei fast allen Connections mit "W" = "Sending reply"
beschäftigt ist:
WWCCWWWWCWWWWWWCWWWWWWWWW_WW_WWWWCWWWWWWWWWWWWCWWWWCWRWWWCS.....
An dieser Stelle stehe ich leider etwas am Schlauch:
Warum hängt der Apache da beim Senden so sehr ? Wo ist der
Flaschenhals ?
Wie kann ich weiter evaluieren, um das Problem zu erkennen ?
System und Apache-Logs geben keinerlei hilfreiche Hinweise.
Ich bin für jede Anregung/Idee dankbar !
Gruß
Marco
--------------------------------------------------------------------------
Apache HTTP Server Mailing List "users-de"
unsubscribe-Anfragen an [EMAIL PROTECTED]
sonstige Anfragen an [EMAIL PROTECTED]
--------------------------------------------------------------------------