Probleme mit Apache 2.0.x, mod_fcgid und php5

[Joe User]

Letztendlich also die gleiche Vorgehensweise/Config wie bei Lighttpd, nur dass Lighty stabiler läuft ;)

[kase]

Letztendlich also die gleiche Vorgehensweise/Config wie bei Lighttpd, nur dass Lighty stabiler läuft ;)

Exakt, der Vorteil beim Lighty ist, dass man dort das Socket DIREKT angeben kann, sprich man kann den php-fcgi-starter komplett vom lighty trennen, und hat dann 2 von einander getrennt arbeitende Systeme. Also im Endeffekt ist die Umsetzung im Lighty sogar noch besser *ggg*

[theomega]

Hoi,
danke für deine Arbeit, nur hat das überhaupt nicht geklappt, die Seite war garnicht mehr ereichbar, alle Requests liefen sich tot. Der Error-Log hat wieder

Code: Select all

[Sun Jan 21 18:48:09 2007] [warn] mod_fcgid: can't apply process slot for /srv/pagenstecher/html/seite/showtopic.php

gezeigt.

Die Konfiguration war genau die gleiche wie bei dir. Irgendwas passt also noch nicht.

Ich kann gerade keine genaueren Infos geben, will den Produktivserver nicht unenutzbar an einem Sonntag abend lassen, ich werde das heute nacht nochmal genauer untersuchen.

So ein Mist, wiso fallen solche Sachen einem eigentlich erst im Produktiveinsatz auf (kein Vorwurf an jemand speziellen, mehr Frust über die Welt). Wenn ich/wir das nicht bald hinbekommen, leg ich ne Nachtschicht ein und schreib die 100 mod_rewrite-regeln um die mich noch am apache halten und geh zum lighttpd. Würde ich aber gerne vermeiden wenns einfacher geht. Vor allem ist mir das Sicherheitssystem vom lighttpd noch sehr unklar, würde mich wieder ein Haufen Zeit kosten, deshalb wäre mir im Moment der Apache wesentlich lieber.

Gruß
TO

[kase]

Diese Zeile killt dir alle Prozesse, die dem Init gehören, also von denen der Parent durch fcgid gekillt wurde:

Code: Select all

ps ax -F | awk '{ if ( $3 == "1" && $1 == "HIER USER EINSETZEN" && $12 == "HIER PHP-BIN EINSETZEN" ) { print "kill " $2 } }' | sh

ps ax -F | awk '{ if ( $3 == "1" && $1 == "timo" && $12 == "/usr/bin/php5-cgi" ) { print "kill " $2 } }' | sh

Schande über mich, falls es irgendwie einfacher gehen sollte :) Der awk Befehl tuts auf jeden Fall ohne Probleme.

Der fertige php-fcgi-starter sieht dann so aus:

Code: Select all

#!/bin/sh
# Alle alten PHP Prozesse, die dem Init gehoeren, killen
ps ax -F | awk '{ if ( $3 == "1" && $1 == "timo" && $12 == "/usr/bin/php5-cgi" ) { print "kill " $2 } }' | sh
# Pfad zur php.ini, ohne / am Ende.
PHPRC="/var/www/fastcgi/timo"
export PHPRC
# Maximale Requests pro php-Prozess, verhindert immer
# groesser werdende php-binarys zB durch memory leaks.
# Nicht zu niedrig waehlen, da sonst bei hoher Load
# die Binarys zu oft neu gestartet werden muessen. (>=5000)
PHP_FCGI_MAX_REQUESTS=11000
export PHP_FCGI_MAX_REQUESTS
# Anzahl an php-fcgi-children (Prozesse), mindestens 2, maximal 100.
# Ein guter Wert (gemessen mit AB (Apache Benchmarking Tool) ist
# "Anzahl gleichzeitiger PHP Zugriffe (concurrency) geteilt durch 4"
PHP_FCGI_CHILDREN=10
export PHP_FCGI_CHILDREN
# IP Adresse, von der connections akzeptiert werden, normalerweise nur localhost
FCGI_WEB_SERVER_ADDRS="127.0.0.1"
export FCGI_WEB_SERVER_ADDRS
exec /usr/bin/php5-cgi

Warum bei dir immer dieser Fehler kommt, ist für mich absolut unverständlich. Wäre gut, wenn du auf deinem Testsystem die Konfiguration mal testen könntest.

Hast du denn überhaupt php-fcgi Prozesse, nachdem du eine php Datei aufgerufen hast? Eventuell schafft dein mod_fcgid nicht mal einen Prozess zu spawnen, warum auch immer?

Die einzigste Möglichkeit, die mir dann noch einfallen würde, ist, dass es wirklich an php 5.2 liegt, weil da einiges am php-fcgi getan wurde. Auch da wäre gut, wenn du das auf deinem Testserver mal probieren könntest, wie gesagt, ich kann deinen Fehler leider nicht reproduzieren.

[kase]

Ich sehe übrigens gerade

libapache2-mod-fastcgi

wurde trotz des FREEZE wieder in Testing migriert, da die Devs wohl die meisten Probleme (alle?) mit Apache2.2 behoben haben.

Siehe Changelog.

Code: Select all

   * transit libapache2-mod-fastcgi for apache2.2
   * Fix in built-in suexec path (Closes: #331617)
   * remove unnecessary libc6 version dependency (Closes: #343519)
   * apply patch to fix that apache2 segv on load (Closes: #343514)

[theomega]

Ich werde erstmal meinen Testserver so einrichtien wie von dir geplant, dann sehen wir ja obs am PHP liegt.

Was heißt das mit dem mod_fastcgi? Ist der fix seitens Debian oder seitens der richtigen Entwickler. Ich hatte leider auch einige Probleme mit mod_fastcgi, deshalb bin ich ja zu fcgid gegangen.

[kase]

Ich werde erstmal meinen Testserver so einrichtien wie von dir geplant, dann sehen wir ja obs am PHP liegt.

Was heißt das mit dem mod_fastcgi? Ist der fix seitens Debian oder seitens der richtigen Entwickler. Ich hatte leider auch einige Probleme mit mod_fastcgi, deshalb bin ich ja zu fcgid gegangen.

mod_fastcgi == Debian

Das Modul wird von den Debian-Devs weiterentwickelt. Selbst andere Distris holen sich IMHO den Source Code vom Debian Team und machen dann entsprechend ihre Packages.

Der damalige Entwickler ist soviel ich weiß seit Mitte 2004 nicht mehr am Projekt beteiligt, oder entwickelt nun direkt bei Debian??? (nicht sicher)

Ansonsten hatte ich auch einige Probleme mit mod_fastcgi. Ich teste gerade, inwieweit diese behoben sind.

[theomega]

So, kleines Statusupdate:
1. Es funktioniert wie du gesagt hast einwandfrei auf meinem Testserver wenn ich mit ab2 teste, keine Fehler, topp! AAABER:
2. Es funktioniert GARNICHT auf meinem Produktivserver: Es wird zwar genau ein PHP-Prozess pro VHost erstellt mit der richitgen Anazhl Childs, nur laufen sich ungefähr 90% aller requests zu tode, die Seite ist unbenutzbar. Am Anfang (die ersten zwei Klicks), dann wird es immer schlimmer. Die Anzahl der Childs (habe 10,25,50,100,200 probiert) spielt dabei keine Rolle.

Die Sache hat zwei Unterschiede:
1. Auf dem Testserver simuliere ich die Last nur mit ab2, auf dem Produktivserver ist sie echt
2. Evtl der wirkliche Grund: Auf dem Tesserver läuft PHP 5.2.x, auf dem Produktivserver nur PHP 5.1.x. Das liegt vor allem daran: die .2.x hat ihren Weg noch nicht zu Gentoo unstable gefunden, ich muss mit einem overlay arbeiten um überhaupt an die 5.2.x zu kommen. Ich bin gerade am installieren, ich hoffe wirklich das es daran liegt, sonst wird es echt misteriös.

Gruß
TO

[theomega]

So, nächstes Update:
Die PHP-Versionen sind nun auch identisch und trotzdem ist die seite nicht zu gebrauchen. Wobei meine Ausführung "die request laufen sich zu tode" falsch ist: Fast alle Requests bekommen eine Antwort, jedoch nach ungefähr 5 sekunden frühestens, also kein Zustand. Haste irgendeine Idee?

[kase]

Ich habe nochmal im PHP-Changelog nachgesehen.

Die Option PHP_FCGI_CHILDREN=0 gibt es erst seit php5.2, vorher musste sie min 1 sein.

Bei php5.2 ist der Default Wert für PHP_FCGI_CHILDREN=0 (also falls nicht angegeben), bei den Versionen davor PHP_FCGI_CHILDREN=8.

=> Du müsstest bei deiner 5.1.6 trotz nicht angegebenem PHP_FCGI_CHILDREN wegen dem Default Wert pro Prozess 8 Children gehabt haben.

Dies wäre zu prüfen, vielleicht läuft dann deine "alte" Konfiguration ohne Probleme mit dem neuen PHP.

Zu deinem Problem. Sagt das error.log immer noch den Mist von wegen Process Slot? Ich hatte diesen Fehler bei all meinen Tests noch kein einziges Mal, irgendwie ist das sehr merkwürdig.

Was ich auch noch herausgefunden habe, die Fehlermeldung "Broken Pipe", die ich bei fcgid oft/hauptsächlich hatte, wenn das Prozessmanagement beim mod_fcgid war, also PHP_FCGI_CHILDREN=0, hängt wohl zusammen mit dem backlog.

Ich habe bei mod_fcgid leider keine Einstellung gefunden, dies zu erhöhen.

-----------

mod_fastcgi habe ich inzwischen auch erfolgreich installiert. Auch dort hatte ich am Anfang Broken Pipe Fehler. Hier gibt es aber eine Einstellung für das backlog, nennt sich -listen-queue-depth, die habe ich einfach von 100 auf 300 erhöht, und siehe da, die 100.000 Requests mit 200er concurreny liefen ohne einen einzigen 500er mehrmals durch.

Code: Select all

 -listen-queue-depth n (100)
    The depth of listen() queue (also known as the backlog) shared by all instances of applications. A deeper listen queue allows the server to cope with transient load fluctuations without rejecting requests; it does not increase throughput. Adding additional application instances may increase throughput/performance, depending upon the application and the host.

[kase]

So, ich gehe jetzt ins Bett.

Falls du noch Lust hast weiter zu testen, und alles nicht mehr weiter hilft, kannst du ja evtl mal die neue Version von mod_fastcgi testen.

Source-Code 2.4.2.orig:
http://ftp.debian.org/debian/pool/non-f ... rig.tar.gz

Source-Code Patch 2.4.2-8:
http://ftp.debian.org/debian/pool/non-f ... -8.diff.gz

fastcgi.conf

Code: Select all

<IfModule mod_fastcgi.c>
  AddHandler fastcgi-script .fcgi
  FastCgiWrapper /usr/lib/apache2/suexec
  FastCgiIpcDir /var/lib/apache2/fastcgi
  FastCgiConfig -maxClassProcesses 1 -maxProcesses 10 -minProcesses 1 -listen-queue-depth 300

  # Einen statischen fastcgi Server brauchen wir inzwischen nicht mehr,
  # jetzt duerfen _endlich_ ALLE fastcgi Server dynamisch sein.
  # FastCgiServer /var/www/php-fcgi-scripts/timo/php-fcgi-starter -user timo -group timo

  AddHandler php-fastcgi .php

  <Location /cgi-bin/php-fcgi-starter>
        SetHandler fastcgi-script
        Options +ExecCGI
  </Location>

  Action php-fastcgi /cgi-bin/php-fcgi-starter
  AddType application/x-httpd-php .php
</IfModule>

FastCgiWrapper = Pfad zum suexec Binary, kann bei dir evtl suexec2 sein.
FastCgiIpcDir = Pfad zu den Sockets
FastCgiConfig: Nicht vergessen maxProcesses auf einen Wert > deinen vHosts mit php-fcgi support zu setzen.

php-fcgi-starter (Datei bei mir: /var/www/php-fcgi-scripts/php-fcgi-starter)

Code: Select all

#!/bin/sh
# Pfad zur php.ini, ohne / am Ende.
PHPRC="/var/www/fastcgi/timo"
export PHPRC
# Maximale Requests pro php-Prozess, verhindert immer
# groesser werdende php-binarys zB durch memory leaks.
# Nicht zu niedrig waehlen, da sonst bei hoher Load
# die Binarys zu oft neu gestartet werden muessen. (>=5000)
PHP_FCGI_MAX_REQUESTS=10000
export PHP_FCGI_MAX_REQUESTS
# Anzahl an php-fcgi-children (Prozesse), mindestens 2, maximal 100.
# Ein guter Wert (gemessen mit AB (Apache Benchmarking Tool) ist
# "Anzahl gleichzeitiger PHP Zugriffe (concurrency) geteilt durch 4"
PHP_FCGI_CHILDREN=20
export PHP_FCGI_CHILDREN
# IP Adresse, von der connections akzeptiert werden, normalerweise nur localhost
FCGI_WEB_SERVER_ADDRS="127.0.0.1"
export FCGI_WEB_SERVER_ADDRS
exec /usr/bin/php5-cgi

vHosts.conf

Code: Select all

        ScriptAlias /cgi-bin/ /var/www/php-fcgi-scripts/timo/
        <Directory "/var/www/php-fcgi-scripts/timo">
                AllowOverride None
                Options +ExecCGI -MultiViews -Indexes
                Order allow,deny
                Allow from all
        </Directory>

Den FCGIWrapper /var/... vom fcgid nicht vergessen aus dem vhost raus zu nehmen...

Anregungen zum "Build" von mod_fastcgi findest du in meinem Howto von damals, müsstest mal schauen in wie weit das noch funktioniert:
http://www.debianhowto.de/doku.php/de:h ... 2_php-fcgi

[kase]

Ok, habe mod_fastcgi wieder runtergeschmissen, hat doch noch einiges nicht so funktioniert wie ich wollte :)

Das Spawnen von dynamischen Prozessen funktioniert mit php 5.2 und mod_fastcgi mehr oder weniger gar nicht. Nach dem 1. Prozess ist Ende. Auch einen Segfault habe ich hinbekommen *gggg*

Je nachdem, wieviel ich auf dem Server noch gemacht habe, hatte ich auch jede Menge Broken Pipes, sprich 500er.

Dies hat mich allerdings wieder auf eine Idee gebracht. :)

Normalerweise hatte ich während den Tests mit PHP_FCGI_CHILDREN=0 "top" laufen, um zu sehen, wie sich die Prozesse entwickeln.

Da top bei einer hohen Refresh Rate auch ein bißchen CPU frisst, habe ich den AB einfach mal ohne top durchlaufen lassen, und siehe da, auch mit dynamischer Konfiguration keinerlei 500er bei 100.000 Requests und 200er concurreny.

Scheinbar sorgt bei solch einer hohen Load (30+) "anderweitige" CPU Last schnell für Fehler.

[cirox]

Hallo,

ich fahre mit folgender Konfiguartion ganz gut. Allerdings libapache2-mod-fastcgi_2.4.2-6_i386.deb und Apache 2.0.54 mit php 5.1.6

in der .conf:

Code: Select all

FastCgiConfig -idle-timeout 300 -killInterval 60 -maxClassProcesses 5 -maxProcesses 400 -minProcesses 0 -multiThreshold 80 -startDelay 5

Oder seht Ihr da gravierende Fehler?

Die Starter sehen so aus (Standard ohnen Optimierung)

Code: Select all

#!/bin/sh
PHPRC="/etc/apache2/pfad"
export PHPRC
PHP_FCGI_CHILDREN=4
export PHP_FCGI_CHILDREN
exec /pfad/php-fcgi

# Einen statischen fastcgi Server brauchen wir inzwischen nicht mehr,
# jetzt duerfen _endlich_ ALLE fastcgi Server dynamisch sein.
# FastCgiServer /var/www/php-fcgi-scripts/timo/php-fcgi-starter -user timo -group timo

ab wann gilt das denn?

Und ich hab nochein anderes Problem was aber mit meiner obigen Config besser geworden ist, vorher hat ich die Standardconfig von kase aus dem howo:

Mit hauen manchmal die fastgi Prozesse ab und verurachen einen hohen Load. Das sieht dann mit "top" so aus, dass die wahrscheinlich nicht richtig beendet werden. Jedenfalls hab dann zum Beispiel:

time
43:31.66

bei einem oder mehreren Prozessen. Normal wäre hier das die sich immer rechtzeitig beenden. Was ist das ?

[kase]

Kann dir nicht genau sagen, ab wann. Lass einfach die Zeile raus und probier es aus. (bzw kommentieren)

Deine 2. Frage habe ich nicht genau verstanden, was meinst du mit abhauen? Wenn ein Prozess eine hohe CPU-Time hat, dann heißt das eigentlich nur, er hat auch sehr viele Anfragen bearbeitet, wo ist das Problem?

[cirox]

Hallo,

zu 2.: Naja kill ich den Prozess manuell geht der Load sofort runter, kill ich Ihn nicht würde er auf ewig so weiterlaufen und der Load des Servers geht nicht runter sondern bleibt meinetwegen auf 5 (normal sind so 0,40 meinetwegen). Ich dachte dass man FastCGI irgendwie sagen kann, dass es nach einer bestimmten Zeit die Prozesse neu startet, um diese Fehler zu vermeiden.

[kase]

Es gibt dafür 2 Parameter:

-killInterval
Bestimmt, nach wieviel Sekunden ein dynamischer PHP Prozess wieder gekillt wird, natürlich nur, wenn er gerade keine Anfrage bearbeitet.

-idle-timeout
Bestimmt, nach welcher Zeit ein Prozess gekillt wird, wenn er sich bei der fastcgi API nicht zurückmeldet, zB wenn sich ein Prozess aufgehängt hat. (Amok laufen != Aufhängen)

Bei dir hört sich das sehr stark nach einem amoklaufendem PHP Prozess an, der zB irgendwie in einer for-while Schleife festhängt oder so.

[cirox]

in der .conf:

Code: Select all

FastCgiConfig -idle-timeout 300 -killInterval 60 ......

jupp, seitdem ich die Werte gesetzt habe ist es auch extrem besser geworden. Habe seitdem nur noch wöchentlich, diese Aufhänger. Was mich aber verwundert ist, dass machmal diese Parameter nicht greifen.

gruß cirox

[kase]

Warum glaubst du denn, dass sie nicht greifen?

Ich denke, das wird 1a funktionieren.

[cirox]

Hallo,

weil der Prozess nur von mir manuell gekillt werden kann. Da es aber besser geworden ist, denke ich das die Einstellungen i der Regel schon greifen. Ich kann mir auch nicht vorstellen, dass zum Beispiel der Prozess einfach so lange immer wieder abgefragt wird, siehe auch Erklärung oben im Thread. Weil iss ja nicht normal unter Fast-CGI, dass die Prozesse dann einfach hängenbleiben (Amok laufen) und ein hohes LOAD verursachen, bzw. müssten Sie ja gerade dann gekillt werden.

[kase]

Woher soll fastcgi denn wissen, ob der Prozess Amok läuft, oder einfach nur ein sehr großes CPU-lastiges Script aufgerufen wurde???

Prozesse werden normalerweise nur gekillt, wenn sie a) idlen oder b) sich nicht zurückmelden. Beides scheint bei dir nicht der Fall zu sein, du sagst ja selbst, der Prozess verursacht eine hohe Load, sprich er "arbeitet", und fastcgi wird sich natürlich davor hüten, arbeitende PHP Prozesse zu killen.

Probier mal ein

http://www.php.net/manual/en/function.s ... -limit.php

zu setzen, vielleicht hilft es ja.