Apache frist RAM ohne Ende

[s20]

Hallo,

auf einem rootserver L habe ich ca. einmal die Woche das Problem, dass bei Besuchen der Suchmaschinenrobots EIN Apache Prozess extrem viel RAM nutzt und dann den Rechner ins swappen bringt. kswapd sehr weit oben in der top liste.

Ich hoste einige Shops mit vielen Unterseiten und mysql als DB dahinter. Ein Großteil der Seiten ist bereits statisch gemacht, weil sich die Shopdaten selten ändern. Dieser statische Teil wird per php include in die dynamischen Seiten geladen. Damit hatte ich die Last zur DB verringern können. Ich kann dann immer nur mit einem restart des apache den RAM freibekommen.

Meine gekürzte Config sieht folgendermassen aus:

Code: Select all

ServerType standalone
ServerRoot "/usr/local/httpd"
LockFile /var/lock/subsys/httpd/httpd.accept.lock
PidFile /var/run/httpd.pid
ScoreBoardFile /var/run/httpd.scoreboard
Timeout 300
KeepAlive On
MaxKeepAliveRequests 100
KeepAliveTimeout 5
MinSpareServers 2
MaxSpareServers 4
StartServers 2
MaxClients 80
MaxRequestsPerChild 500

Ich verwende Apache apache-1.3.27-17 und fast die Standardconfig.

Würde mich sehr freuen, wenn mir jemand bei der evtl. unpassenden config helfen kann. maxrequestperchild stand einige Zeit auf 5000 mit dem selben Problem.

Vielen Dank
S20

[captaincrunch]

Ein free und die Ausgabe von ps aux | grep httpd wären zur Analyse sehr hilfreich.

[oxygen]

Hm, wenn ich das so sehe ist alles falsch konfiguriert.

Timeout zu hoch
MaxKeepAliveRequests und KeepAliveTimeout zu niedrig
MinSpareServers und MaxSpareServers viel zu niedrig
MaxClients würde ich sagen zu niedrig, aber das kommt auf die Situation an
MaxRequestsPerChild sollte aus oder sehr hoch sein (>10000)

[s20]

So ein zufall, bin gerade wieder dran:

Code: Select all

 PID USER     PRI  NI  SIZE  RSS SHARE STAT %CPU %MEM   TIME COMMAND
    4 root      14   0     0    0     0 SW    3.3  0.0  29:27 kswapd
 4959 root      13   0   944  944   740 R     0.7  0.3   0:00 top
  638 wwwrun     9   0  238M  86M 44200 D     0.1 35.6   7:34 httpd
 4935 wwwrun     9   0 16932 5448  4660 S     0.1  2.1   0:00 httpd
 4936 wwwrun     9   0 16820 5320  4656 S     0.1  2.1   0:00 httpd
    1 root       9   0    60   48    48 S     0.0  0.0   0:35 init
    2 root       9   0     0    0     0 SW    0.0  0.0   0:06 keventd

Code: Select all

root     19003  0.0  0.3 59424  756 ?        S    Dec25   0:13 /usr/sbin/httpd -f /etc/httpd/httpd.conf -D SSL
wwwrun   20553  0.0  0.0 59304  140 ?        S    00:15   0:00 /usr/sbin/fcgi- -f /etc/httpd/httpd.conf -D SSL
wwwrun     638  3.7 46.4 291432 115224 ?     D    16:28   7:39 /usr/sbin/httpd -f /etc/httpd/httpd.conf -D SSL
wwwrun    3962 13.6 39.6 272416 98424 ?      D    19:05   6:37 /usr/sbin/httpd -f /etc/httpd/httpd.conf -D SSL
wwwrun    3990  0.0  1.7 59760 4216 ?        S    19:06   0:02 /usr/sbin/httpd -f /etc/httpd/httpd.conf -D SSL
wwwrun    4256  0.1  1.7 59800 4232 ?        S    19:18   0:02 /usr/sbin/httpd -f /etc/httpd/httpd.conf -D SSL
wwwrun    4533  0.0  1.7 59840 4388 ?        S    19:31   0:01 /usr/sbin/httpd -f /etc/httpd/httpd.conf -D SSL
wwwrun    4550  0.1  1.7 59832 4440 ?        S    19:32   0:01 /usr/sbin/httpd -f /etc/httpd/httpd.conf -D SSL
root      4971  0.0  0.1  1328  408 pts/1    D    19:54   0:00 grep httpd

Könntest du deine Hinweise etwas präzisieren øxygen? Die Ausgabe von free deutet sicher wieder darauf, dass ca 300MB Swap genutzt werden. Konkreter output von free habe ich leider vergessen. :-(

Danke S20

[rootmaster]

Die Ausgabe von free deutet sicher wieder darauf, dass ca 300MB Swap genutzt werden. Konkreter output von free habe ich leider vergessen. :-(

versuchs mal hiermit...
http://httpd.apache.org/docs/mod/core.html#rlimitmem

"back to the roots"

[s20]

Danke für den Hinweis rootmaster.

Ich habe RLimitMEM max max eingestellt. Leider ist die Doku zu diesem Parameter nicht so ausführlich. Haltet ihr die Einstellung für sinnvoll.

...max to indicate to the server that the limit should be set to the maximum allowed by the operating system configuration

Der Parameter betrifft im übrigen nur die Kinder der Kinder.

Danke S20

[flo]

Die Maxclients sind mit 80 definitiv zu hoch - gerade auf nem rootserver L, wenn dazu noch eine MySQL läuft. 20 wären da das Maximum, Deine Spareinstellungen bei den Spareservern noch dazu, dann macht Dein Apache sich überflüssige Arbeit damit, ständig Prozesse zu beenden und zu starten.

Code: Select all

wwwrun     638  3.7 46.4 291432 115224 ?     D    16:28   7:39 /usr/sbin/httpd -f /etc/httpd/httpd.conf -D SSL

Wenn Dir so etwas mal wieder auffält, schau Dir die Logs der virtuellen Hosts an - da liegt was im Argen ... daß der Prozeß plötzlich 300MB braucht, könnte an nem Programmierfehler liegen.

flo.

[s20]

Gibt es denn eine optimale Konfigurationseinstellung für nen rootserver L ? Ich denke über try and error komme ich dem Problem nicht nahe, da ich den Fehler nur schwer simulieren kann.

Gruß S20

[Joe User]

JFYI - httpd-2.0.x/STATUS

Code: Select all

[...snip...]

PRs that have been suspended forever waiting for someone to
put them into 'the next release':

[...snip...]
      PR#793: RLimitCPU and RLimitMEM don't apply to all children like they should
        Status:

[...snip...]

[oxygen]

Die Maxclients sind mit 80 definitiv zu hoch - gerade auf nem rootserver L, wenn dazu noch eine MySQL läuft. 20 wären da das Maximum, ...

Also sowas höre ich zum ersten mal. Mit Maxclients 20 bräuchte ich meine Apaches gar nicht erst starten, da eh 4/5 der User nichts zu Gesicht bekämen. Das standardmäßig einkompilierte Maximum von 256 finde ich für stark frequentierte Server sogar schon recht eng.

Zum Vergleich auf meinem Root L:

Code: Select all

# netstat -n|grep 80|grep ESTABLISHED|wc -l
     98

# ps aux|grep httpd|wc -l
    114

# ps aux|grep mysqld|wc -l
     17

# free
             total       used       free     shared    buffers     cached
Mem:        247972     239348       8624          0      12132      67612
-/+ buffers/cache:     159604      88368
Swap:       265064      55864     209200

Also alles Okay. Der Fehler von s20 wird wohl eher in einem Amok gelaufenden Script begründet sein...

[flo]

@oxygen, das war meine Erfahrung mit einer dicken Datenbankseite auf einem rootserver L.

Apache 2 auf meiner jetzigen Kiste läuft komischerweise auch mit weniger Ressourcen ...

Aber natürlich ist das davon abhängig, was auf der Kiste läuft, wie die Programmierung der Seiten aussieht und ob Apache und PHP schmal oder eher nicht gebaut sind.

flo.

[s20]

@øxygen,

welche werte würdest du denn für die apache config vorschlagen? Die Scripte selbst sind alle sehr einfach gehalten. Ich denke eher, dass die Anzahl paralleler Zugriffe auf den Server problematisch werden, wenn die suma robots kommen.

Danke S20

[oxygen]

Ein Anfang wäre:

Code: Select all

Timeout 60 
KeepAlive On 
MaxKeepAliveRequests 300 
KeepAliveTimeout 120 
MinSpareServers 5
MaxSpareServers 50 
StartServers 10 
MaxClients 100 
MaxRequestsPerChild 20000 

[nn4l]

@øxygen:

verwendest Du Apache 1.3 oder 2.0?

Falls 1.3, dann ist m.E. dein MaxClients Setting ziemlich hoch.

Wenn tatsächlich mal 100 Clients gleichzeitig zugreifen, hast Du 100 Apache Prozesse gleichzeitig laufen. Jeder httpd braucht wenigstens 3 MByte RAM, meistens mehr (bei mir ca. 15 MByte, wegen eines großen PHP CMS und mod_php). Also allokierst du zu diesem Zeitpunkt dann etwa 300 MByte RAM.

Auf deinem Server scheint das so gerade eben hinzuhauen, d.h. alle httpd-Prozesse brauchen nur wenig RAM, aber für viele andere User trifft das nicht zu.

Auf meinem Server mit 256 MByte RAM kann ich maximal MaxClients 15 einstellen.

Ich bin auch der Meinung, KeepAliveTimeout 120 ist viel zu hoch, weil jeder httpd dann 120 Sekunden auf die nächste Aktion desselben Clients wartet und somit blockiert ist. D.h. kommt ein anderer User, muss ein neuer httpd gestartet werden. Setzt man KeepAliveTimeout deutlich niedriger (z.B. 5), können weniger httpds mehr Clients (nacheinander) bedienen. Probier doch mal, ob mit einem niedrigen Wert sich auch die ESTABLISHED connections verringern.


@s20: das Problem ist der unmäßige RAM Verbrauch. Ich tippe mal auf Speicherleck oder einen Programmierfehler. Evtl. PHP als CGI laufen lassen, nicht als mod_php.

Ich würd folgendes machen:

1. ulimit ins apachectl startscript aufnehmen, so dass jeder Apache Prozess sich sagen wir max. 20 MByte RAM genehmigen kann. Wenn ein User das überschreitet, kriegt er halt einen 500er Fehler. Sein Problem.

2. MaxClients=10 (10 * 20 MByte + 56 MByte für MySQL und sonstiges sollte so gerade eben auf einem 256 MByte rootserver passen)

3. KeepAliveTimeout=5

4. MaxRequestsPerChild=500 scheint sinnvoll. Es ist von der Performance her völlig egal, ob alle paar Minuten ein httpd beendet und neu gestartet wird, hilft aber gegen Speicherlecks.

[rootmaster]

Der Parameter betrifft im übrigen nur die Kinder der Kinder.

okay, scheint so, dass diese direktive in deinem fall nicht unbedingt greift; dann solltest du es - wie schon gesagt - mit "ulimit" im startskript probieren.

"back to the roots"

[oxygen]

@øxygen:

verwendest Du Apache 1.3 oder 2.0?

Falls 1.3, dann ist m.E. dein MaxClients Setting ziemlich hoch.

Wenn tatsächlich mal 100 Clients gleichzeitig zugreifen, hast Du 100 Apache Prozesse gleichzeitig laufen. Jeder httpd braucht wenigstens 3 MByte RAM, meistens mehr (bei mir ca. 15 MByte, wegen eines großen PHP CMS und mod_php). Also allokierst du zu diesem Zeitpunkt dann etwa 300 MByte RAM.

Auf Server von dem der Auszug stammt setzte ich 1.3 ein, jedoch vergass ich zu erwähnen das der Server 512 MB Ram hat. Jedoch finde ich 15 MB pro Prozess ist sehr hoch. Meine httpds brauchen knapp 5 MB, und ich setzte auch mod_php und mehrere große Anwendungen ein (2x Woltlab Burning Board, 1x Invision Power Board, geeklog etc)

Auf deinem Server scheint das so gerade eben hinzuhauen, d.h. alle httpd-Prozesse brauchen nur wenig RAM, aber für viele andere User trifft das nicht zu.

Dann machen die wohl was falsch, keine Ahnung ;)

Auf meinem Server mit 256 MByte RAM kann ich maximal MaxClients 15 einstellen.

Ich bin auch der Meinung, KeepAliveTimeout 120 ist viel zu hoch, weil jeder httpd dann 120 Sekunden auf die nächste Aktion desselben Clients wartet und somit blockiert ist. D.h. kommt ein anderer User, muss ein neuer httpd gestartet werden. Setzt man KeepAliveTimeout deutlich niedriger (z.B. 5), können weniger httpds mehr Clients (nacheinander) bedienen. Probier doch mal, ob mit einem niedrigen Wert sich auch die ESTABLISHED connections verringern.

Da hast du recht, es werden weniger Childs gespawnt. Aber ist die Frage ob man das will. Die 2 Minuten haben sich als gute Zeitspanne herausgestellt, für User die die sich zügig durchklicken, liegt der Abstand zwischen 2 Anfragen deutlich darunter. Es wird also nicht dauern die Verbindung auf und abgebaut, was sich angenehm in der Geschwindigkeit niederschlägt. Ich habe mal die durchschnittliche Zeit zwischen zwei Zugriffen von Google beobachtet, die liegt zwischen 20-60 Sekunden, wäre also noch im Keepalive Bereich.
Leider hat das Keepalive keinen Einfluss da Google nur HTTP/1.0 benutzt. :(

@s20: das Problem ist der unmäßige RAM Verbrauch. Ich tippe mal auf Speicherleck oder einen Programmierfehler. Evtl. PHP als CGI laufen lassen, nicht als mod_php.

Am besten direkt Apache und PHP schlank neubauen.

Ich würd folgendes machen:

1. ulimit ins apachectl startscript aufnehmen, so dass jeder Apache Prozess sich sagen wir max. 20 MByte RAM genehmigen kann. Wenn ein User das überschreitet, kriegt er halt einen 500er Fehler. Sein Problem.

Naja. Ich würde die Maschine eher Swappen lassen, als User auszusperren...

2. MaxClients=10 (10 * 20 MByte + 56 MByte für MySQL und sonstiges sollte so gerade eben auf einem 256 MByte rootserver passen)

3. KeepAliveTimeout=5

Wenns hilft...

4. MaxRequestsPerChild=500 scheint sinnvoll. Es ist von der Performance her völlig egal, ob alle paar Minuten ein httpd beendet und neu gestartet wird, hilft aber gegen Speicherlecks.

So niedrig würde ich es dennoch nicht stellen. Besonders bei einer derart niedrigen Zahl an Childs. 2000 fände ich schon sinnvoller.

[alexander newald]

Naja. Ich würde die Maschine eher Swappen lassen, als User auszusperren...

Sorry, das ist falsch. Lieber KeepAliveTimeout runtersetzen. Es gibt nichts schlimmeres, als wenn der Indianer oder Apache Swappen

[oxygen]

Findest du? Also da schlimmste Situation in die ich als Verantwortlicher kommen kann, ist das die Seiten nicht erreichbar sind. Verzögerte Auslieferung ist nicht schön... aber immer noch besser als keine Auslieferung.

[alexander newald]

Aber dann ist der Server zu klein oder die Software nicht richtig eingestellt - ok, das Ganze ist natürlich Ansichtssache...

[flo]

Ich bin mit den MaxClients wegen folgenden Falles vorsichtig:

Ich hatte früher ein Setup mit getrennten MySQL und Webservern, eine Seite macht allerdings traditionsgemäß zu bestimmten Zeiten massive Load, und just an so einem Abend - ich wußte davor nichts - knallt der Load der Maschine auf 50.00 hoch, dann knapp 90.00, dann war es aus, per SSH ging nichts mehr. Unter dieser Last fiel dann auch das administrieren zusammen mit experimentieren, und halbwegs stabil lief die Geschichte erst, nachdem ich angefangen habe, massiv die Anzahl der gleichzeitigen Visits zu begrenzen. Eine nicht erreichbare Seite war hier nicht so schlimm wie eine Fehlermeldung, die erst nach Minuten kommt.

Nach einer Analyse über die MySQL-Query-Logs kam ich dann dahinter, warum das so war - eine Anfrage, die das CMS gleich zur Initialisierung der Seite benötigt hat, dauerte > 10 Sekunden, fasste dabei per Jion drei Tabellen (ohne sec. Keys) und mit > 20.000 Einträgen zusammen.

Duch die Anzahl der gleichzeitigen Zugriffe bei MaxCLients 80 (meine Anfangseinstellung) hat sich der Load aufgeschaukelt, weil der Datenbankserver nicht hinterherkam, vom Speicherbedarf der Arrays im PHP ganz zu schweigen.

Das war auf SuSE 7.3 mit einem relativ üppigen Apachen (1.3.27) und PHP (4.2.3). Jetzt, auf einer Debian-Basis mit Apache (2.0.48) und PHP (4.3.4) scheint mir das ganze performanter und ressourcenschonender zu laufen. Statt 26MB braucht ein Prozeß jetzt "nur" noch 14MB. Anzhal der virtuellen Hosts statt > 300 jetzt ca. 30.

Nur meine Erfahrung ...

Aber oxygen läßt seine Kiste ganz schön rauchen, wahrscheinlich steht das Ding bei 1und1 in der Kantine und die machen das Mittagessen darauf ... ;-)

flo.

[s20]

Hallo,

danke für die vielen nützlichen Hinweise. Ich denke, dass das keepalivetimeout der Faktor ist. Jede einzelne Anfrage durch einen robot ist immer nur sehr kurz. Dennoch fragt der bot nahezu parallel mehrere Seiten an. Dafür ist nicht zwingend pro Seite ein neuer Apache Prozess nötig. Eher einer für den gesamten botbesuch. Ich teste das ganze mal mit 60 sekunden keepalivetimeout und berichte natürlich über veränderungen. Ã?ber weitere Hinweise freue ich mich ebenfalls.

Danke
S20

[oxygen]

Aber oxygen läßt seine Kiste ganz schön rauchen, wahrscheinlich steht das Ding bei 1und1 in der Kantine und die machen das Mittagessen darauf ... ;-)

Der Load hält sich in Grenzen:

Code: Select all

 3:37am  up 76 days, 14:57,  2 user,  load average: 0.17, 0.16, 0.21

Geht selten über 0.5

s20: Wie ich bereits oben sagte, keepalive hat keinen Einfluss auf Google (wie es mit anderen Bots aussieht, kA) da Google HTTP/1.0 benutzt, welches keine persistenten Verbindungen unterstützt.

[s20]

Hallo,

es lag zu hoher Wahrscheinlichkeit an der flush Funktion von php die ich zur verspäteten Ausgabe von Inhalten nutze. An die hatte ich gar nicht mehr gedacht. :-( Darauf hätte ich ja selber kommen können. Tut mir leid. Trotzdem hat der Thread viele interessante Infos.

Dabke
S20

[pg-computer]

Hoi Hoi,


also meine Apache Prozesse sind auch relativ groß...

Auszug top:

PID USER PRI NI SIZE RSS SHARE STAT %CPU %MEM TIME COMMAND
4830 wwwrun 9 0 25524 24M 22476 S 0.0 10.2 0:04 httpd
4829 wwwrun 9 0 25292 24M 22524 S 0.0 10.1 0:04 httpd
4831 wwwrun 9 0 24992 24M 22416 S 0.0 10.0 0:02 httpd
4822 wwwrun 9 0 24972 24M 22412 S 0.0 10.0 0:02 httpd
4824 wwwrun 9 0 24924 24M 22408 S 0.0 10.0 0:03 httpd
4827 wwwrun 9 0 24864 24M 22400 S 0.0 10.0 0:02 httpd
4825 wwwrun 9 0 24856 24M 22400 S 0.0 10.0 0:03 httpd
4828 wwwrun 9 0 24808 24M 22436 S 0.0 9.9 0:01 httpd
4823 wwwrun 9 0 24680 24M 22416 S 0.0 9.9 0:02 httpd
4826 wwwrun 9 0 24588 24M 22384 S 0.0 9.9 0:02 httpd
12526 root 8 0 22516 21M 22284 S 0.0 9.0 0:07 httpd
4753 wwwrun 9 0 21940 21M 20540 S 0.0 8.8 0:00 httpd
348 mysql 9 0 17556 11M 1816 S 0.0 4.6 0:06 mysqld
350 mysql 9 0 17556 11M 1816 S 0.0 4.6 0:08 mysqld
351 mysql 9 0 17556 11M 1816 S 0.0 4.6 0:27 mysqld



Weiß aber auch nicht genau, warum die so riesig sind....
Hat auf jeden Fall noch keine Probleme geben... ist auf ner SuSE 7.2

ach stimmt, das sind ja Childprozesse :-D
Die belegen ja zusammen nur den Speicher.. also die 24 MB :-D


Gruß


Peter

[bodo]

Hallo,

ich hätte eine kleine Frage zu dem Timeout Wert,

Ein Anfang wäre:

Code: Select all

Timeout 60 
KeepAlive On 
MaxKeepAliveRequests 300 
KeepAliveTimeout 120 
MinSpareServers 5
MaxSpareServers 50 
StartServers 10 
MaxClients 100 
MaxRequestsPerChild 20000 

sind 60 Sekunden nicht etwas knapp?

Weil diese 60 Sekunden sind ja die Zeit die maximal zwischen dem Aufbau der Verbindung und der eigentlichen Anfrage liegen darf, außer dem begrenzt er die maximale Zeit die ein Script vom Server ausgeführt werden kann bevor dieser die Verbindung schließt.

In den Büchern die ich bis jetzt gelesen habe geht die Tendenz eher zum erhöhen (300s +) dieses Wertes als zum erniedrigen.

Gibt es einen bestimmten Grund weshalb du den Wert runter gesetzt hast?

Mfg,
Bodo