Apache 100% CPU Last

[Thorsten]

Ich habe in den letzten Tagen ein 'etwas merwürdiges' Verhalten von Apache festgestellt. Bis zum gestrigen Neustart der httpd Prozesse hat Apache von einem auf den anderen Tag 100 % user load verursacht. Die Konfiguration wurde nicht verändert, es wurde keinerlei Software installiert. Auch an den Logfiles ist nichts ungewöhnliches zu erkennen.
Das ganze ist hier ganz gut zu erkennen.
Hat irgend jemand eine Ahnung woran es noch liegen kann?

mfG
Thorsten

 

[Huschi]

Hat irgend jemand eine Ahnung woran es noch liegen kann?

Nicht wirklich. Wenn ich das im MRTG richtig sehe, ging es ja fast 24h so. Ich war aber in der Zeit hier im Forum und hab keine Performance-Probleme festgestellt. Evtl. hat sich lediglich ein Apache-Thread weggehängt. Gibt es vieleicht einen Eintrag im Logfile mit "lost Child coming home" zur restart-Zeit?

huschi.

 

[Thorsten]

Lost Child war das Stichwort. Und nicht nur das:

child pid 21818 exit signal Segmentation fault (11)

mfG
Thorsten

 

[Huschi]

Dafür gäbe es dutzende Erklärungen. Rausfinden kann das aber letztendlich nur ein Apache-Entwickler wenn er ein Core-File davon hätte.
Von daher mach Dir keine Gedanken.

Falls es ein Memory-Leak war, könnte man sowas evtl. umgehen indem man inter httpd.conf 'MaxRequestsPerChild' und/oder 'ThreadsPerChild' auf etwas anderes als 0 setzt. (Üblich wäre z.B. 100 und 50.)
Hiermit wird geregelt, wielange ein Child/Thread aktiv bleibt. Im Falle eines Memory-Leak's (egal ob im Apache selbst, PHP oder sonst einem Modul) kann sich dieses nicht so schnell expandieren, bzw. wird irgendwann vom Parent abgefangen.

Ob es dann aber in der Praxis wirklich hilft ist immer eine andere Sache...

huschi.

 

[Thorsten]

Das Problem ist wieder aufgetreten. Ich werde mal versuchen Huschi's Gegenmaßnahmen umzusetzten.

mfG
Thorsten

 

[Hotte]

Das Problem ist wieder aufgetreten. Ich werde mal versuchen Huschi's Gegenmaßnahmen umzusetzten.

mfG
Thorsten

strace ist dein Freund

strace -p <pid>

evtl durch less pipen bzw. die Ausgabe für ein paar Sekunden in eine Datei umleiten.

 

[Thorsten]

Hm, schön und gut. Datei liegt hier.
Schlau werde ich ehrlich gesagt nicht daraus .

mfG
Thorsten

 

[mbroemme]

select, pselect, FD_CLR, FD_ISSET, FD_SET, FD_ZERO - synchronous I/O multiplexing

Wenn das auf einem vSERVER ist mal gucken was bei /proc/user_beancounters bei numflock steht.

 

[Hotte]

viele selects

man select
select, pselect, FD_CLR, FD_ISSET, FD_SET, FD_ZERO - synchronous I/O multiplexing
The functions select and pselect wait for a number of file descriptors to change status.

Platte/FS fritte?

 

[Thorsten]

Das müsste mir mal jemand übersetzten .
Es ist kein vServer. Dedizierter Server bei Strato. Confixx Pro, 3-4 MySQL Datenbanken, Apache, Postfix und ntop.
Ansonsten macht er ja auch keine Zicken.

mfG
Thorsten

 

[Huschi]

select(0, NULL, NULL, NULL, {1, 0})

Dieser code bewirkt nichts. Da alle drei Filedescriptor-Array leer sind wartet er zwangsweise auf den Timeout (hier eine Sekunde). select wird benutzt um non-blocking zu arbeiten. D.h. die CPU-Kapazität für andere Threads freizugeben.

Die Zeilen

select(8, NULL, [7], NULL, {0, 0})      = 1 (out [7], left {0, 0})
wait4(-1, 0xbffff638, WNOHANG, NULL)    = 0

bedeuten, daß er auf insgesammt 8 Dateien/sockets (mit einem Timeout=0 == unendlich) wartet, um schreiben zu können.
Parallel wartet anscheinend ein Thread mit wait4 auf (evtl.) den Thread mit dem select, um sich mit diesem zu syncronisieren.
Beide Befehle entlasten die CPU eigendlich, da sie innerhalb des Kernels verarbeitet werden.

War das wirklich zu einem Zeitpunkt mit 100%iger Auslastung von Apache?
Dann wäre das sehr seltsam.

huschi.

 

[Thorsten]

Hallo Huschi,
erstmal vielen Dank für die Erklärung. Einen genauen Zeitpunkt an dem die CPU Last so dramatisch ansteigt kenne ich nicht. Es ist jedenfalls so,das der Webserver eine ganze Zeit lang läuft und dann schlagartig auf 100% geht.
Wenn ich jetzt in apachectl restart mache geht die Last wieder auf Null.

mfG
Thorsten

 

[Thorsten]

Hallo Huschi!

Falls es ein Memory-Leak war, könnte man sowas evtl. umgehen indem man inter httpd.conf 'MaxRequestsPerChild' und/oder 'ThreadsPerChild' auf etwas anderes als 0 setzt. (Üblich wäre z.B. 100 und 50.)

Nachdem ich diese Konfigurationsänderung durchgeführt habe, hat sich Apache scheinbar beruhigt. Das Ganze ist jedenfalls bis jetzt nicht mehr aufgetreten.

mfG
Thorsten