Viele laufende Prozesse in ps aux

G

gimahHOT

Grünschnabel
Hallo!

Wir haben einen dramatischen Performanceabfall auf unserem Server festgestellt.

Über SSH und den Befehl ps aux wurde erkannt, dass viele Prozesse liefen, die nicht mehr benötigt wurden aber nicht geschlossen wurden.

Hier ein Auszug aus der Ausgabe von ps aux:
USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
u3663 20056 25.4 1.6 44784 33476 ? R 07:38 37:01 /usr/local/apache/share/cgi-bin/php4 /kunden/homepages/2/d10613/htdocs/main.php
u3663 20058 25.2 1.4 39748 30316 ? R 07:38 36:47 /usr/local/apache/share/cgi-bin/php4 /kunden/homepages/2/d10613/htdocs/main.php
u3663 20305 24.2 1.6 44524 34744 ? R 07:41 34:37 /usr/local/apache/share/cgi-bin/php4 /kunden/homepages/2/d10613/htdocs/main.php
u3663 21415 19.4 1.6 45372 34732 ? R 07:57 24:47 /usr/local/apache/share/cgi-bin/php4 /kunden/homepages/2/d10613/htdocs/main.php
u3663 21416 19.4 1.4 43144 30532 ? R 07:57 24:46 /usr/local/apache/share/cgi-bin/php4 /kunden/homepages/2/d10613/htdocs/main.php
u3663 21678 18.8 1.7 46192 35248 ? R 08:00 23:22 /usr/local/apache/share/cgi-bin/php4 /kunden/homepages/2/d10613/htdocs/main.php
......

insgesamt ergab sich eine Auslastung der CPU von 484%.

Durch kill wurden die Porzesse beendet und die Performance war wieder OK, die Analyse warum diese Prozesse nicht austomatisch geschlossen wurden steht jedoch noch aus.

Kann jemand zu folgenden Fragen etwas sagen:
1.) kann man die parameter feststellen, die den main.php prozeszz angestoßen haben? z.B. ... main.php?top=900&prod_id=4637 oder ähnlich
2.) kann man irgendwie tiefergehend analysieren, wo genau der Prozess hängen geblieben ist?
3.) gibt es ein analyse-tool hierfür?
4.) gibt es Debug-Dienstleister, die eine Optimierung vornehmen?
5.) einzelne Prozesse zeigen eine CPU-Nutzung von 25% an. Kann man irgendwie diese Ausnutzung limitieren?

Vielen Dank für Antworten
 
gimahHOT schrieb:
Kann jemand zu folgenden Fragen etwas sagen:
1.) kann man die parameter feststellen, die den main.php prozeszz angestoßen haben? z.B. ... main.php?top=900&prod_id=4637 oder ähnlich
2.) kann man irgendwie tiefergehend analysieren, wo genau der Prozess hängen geblieben ist?
3.) gibt es ein analyse-tool hierfür?
4.) gibt es Debug-Dienstleister, die eine Optimierung vornehmen?
5.) einzelne Prozesse zeigen eine CPU-Nutzung von 25% an. Kann man irgendwie diese Ausnutzung limitieren?

Zuerstmal: Herzlich Willkommen auf unserem Board. Deine Fragestellung ist vorbildlich und sollte zur (schnelleren) beantwortung beitragen. Weiter so :).

Dann, sorry. Ich bin kein PHP-Freak, versuche aber dein Frage dennnoch soweit es geht zu beantworten.

zu 1. Wenn du als Webserver einen Apache verwendest, können evtl die Log Datein unter /var/log/apache/ weiterhelfen. Dort gibt es wahrscheinlich access.log und error.log dateien. Wenn du Glück hast, steht dein Problemkind mit Parametern in einer error.log.

zu 2. Mehr als die Logfiles fällt mir hier nicht ein. Sorry.
zu 3. Auch hier muss ich passen. Hatte bis jetzt noch kein derartiges Problem. Aber soweit ich weiss gibt es keine Debugtools für PHP (nachteil dieser Sprache).
zu 4. Jeder Webdesigner sollte da was Optimieren können *denk*.
zu 5. Es gibt die möglichkeit prozesse zu priorisieren. Der Befehl hierfür schimpft sich "nice" (thx zico *g). Die Manpages werden dir bestimmt weiterhelfen. Ausserdem lässt sich über die Konfiguration des Apache einiges steuern.
Code:
KeepAlive On
MaxKeepAliveRequests 100
KeepAliveTimeout 15
MinSpareServers 2
MaxSpareServers 5
StartServers 2
MaxClients 8
MaxRequestsPerChild 100
Das sind nur so ein paar Optionen die dich vielleicht etwas weiter bringen.

Viel Erfolg.

Havoc][
 
Hallo!

Danke für die Antwort.

Ad 1.)
Wir konnten tatsächlich mit hilfe der Log-files und den darin befindlichen timestamps der Aufrufe die Vorgänge ausfindig machen, die zu einer Endlosschleife führten, weil Seiten die aus Datenbankeinträgen generiert wurden nicht merh vorhanden waren. Somit konnte das Hauptproblem recht einfach von Programmiererseite gelöst werden.

Ad 5.)
Wir werden nun die Prozesse untersuchen, die recht hohe CPU Auslastung mit sich ziehen (wenn auch nur sehr kurzzeitig) und mithilfe Deiner genannten Möglichkeiten (nice und apache options) versuchen eine optimierung vorzunehmen.

Jetzt läuft erstmal alles wieder recht glatt. War nur eine nervige Arbeit, die Prozesse zu verfolgen und gleichzeitig die nicht merh benötigten Prozesse manuell zu beenden um Serverleistung wieder freizugeben bis die Programmierseite den Fehler behoben hatte. Und dann ausgerechnet an einem Wochenende, wo auch noch Artikel bei Spiegel-online und im Manager-magazin über uns erschienen und der Traffic eh schon sehr hoch war.
 
gimahHOT schrieb:
Danke für die Antwort.
Bitte. Gern geschehen. Gut das überhaupt eine Response von dir gekommen ist :). Wenn man hört das es wenigstens teilweise funktioniert hat, liest man sich den Post sogar mehrmals durch :). Geht dann runter wie Honig *ggg*.

gimahHOT schrieb:
Ad 1.)
Wir konnten tatsächlich mit hilfe der Log-files und den darin befindlichen timestamps der Aufrufe die Vorgänge ausfindig machen, die zu einer Endlosschleife führten, weil Seiten die aus Datenbankeinträgen generiert wurden nicht merh vorhanden waren. Somit konnte das Hauptproblem recht einfach von Programmiererseite gelöst werden.
Hört sich ja fast so an, als wären immer die Programmierer schuld :D. Nein Quatsch. Super das die Logfiles euch weiter geholfen haben :).

gimahHOT schrieb:
Ad 5.)
Wir werden nun die Prozesse untersuchen, die recht hohe CPU Auslastung mit sich ziehen (wenn auch nur sehr kurzzeitig) und mithilfe Deiner genannten Möglichkeiten (nice und apache options) versuchen eine optimierung vorzunehmen.

Jetzt läuft erstmal alles wieder recht glatt. War nur eine nervige Arbeit, die Prozesse zu verfolgen und gleichzeitig die nicht merh benötigten Prozesse manuell zu beenden um Serverleistung wieder freizugeben bis die Programmierseite den Fehler behoben hatte. Und dann ausgerechnet an einem Wochenende, wo auch noch Artikel bei Spiegel-online und im Manager-magazin über uns erschienen und der Traffic eh schon sehr hoch war.
Ich weiss nicht ob nice und die apache options euch langfristig weiter helfen. Hierzu sollte sich normalerweise eher ein PHP Coder zu Worte melden. Aber sollte trotzdem alles gut gehen, dann: Glückwunsch :).

Havoc][
 
Hallo!

Wir planen nun (auch aus Performance-Gründen) von CGI auf MOD_PHP umzustellen.

a) Hat jemand dazu Erfahrungen?
b) Was ist zu beachten?
c) Wo liegen evtl. Nachteile?
d) Können die Scripte 1:1 übernommen werden oder sind anpassungen nötig?


@Havoc][
Hört sich ja fast so an, als wären immer die Programmierer schuld
Ja, sieht ganz so aus als wenn zumindest eine Teilschuld dort liegen würde. Programmierfehler in Verbindung mit Mängeln in der Spezifikation. Es wurde auf Seiten geleitet, die durch die dynamische Generierung aus der Datenbank nicht mehr vorhanden waren. Diese waren jedoch im Google-Index noch gelistet und somit konnten Google-User und der Google-Robot selbst diese Links aufrufen und zu diesem Problem führen.


Danke für Antworten
 

Ähnliche Themen

NagiosGrapher 1.7.1 funktioniert nicht

Statistikprogramm R

HP PSC 2175 - CUPS druckt nicht

Rollei Mini Wifi Camcorder

Samba PDC - Probleme mit der Vertrauensstellung

Zurück
Oben