MaxRequestsPerProcess mod-fcgid

[cirox]

Hallo,

unglücklicherweise? habe ich in allen Wrapper n Starter folgenden Codeschnipsel unter anderem drinnen zu stehen:

Code: Select all

PHP_FCGI_MAX_REQUESTS=5000
export PHP_FCGI_MAX_REQUESTS

Nun habe ich aber laut Doku in der ".conf" festgeschrieben:

Code: Select all

MaxRequestsPerProcess 500

da ich fcgid und PHP einsetze

Frage: Was überschreibt hier welchen Parameter? Gilt nun der aus dem Starter oder der in der .conf? M.E. sind es ja wohl die Gleichen?

gruß cirox

[kase]

Ich bin mir nicht sicher, ob mod_fcgid einfach die ENV-Variable für PHP setzt, oder dort einen eigenen Mechanismus implementiert.

Falls es nur die ENV-Variable setzt, sollte der Starter den Wert überschreiben, da er sie später setzt als mod_fcgid. Falls es eine Eigenentwicklung ist, sollten beide Limits greifen, bzw das Limit, das niedriger ist.

Setze doch den Wert in der mod_fcgid.conf einfach auf -1, dann kannst du dir ganz sicher sein, dass immer das Limit im fcgi-starter greift.

[cirox]

erstmal thx für die schnelle Antwort

Naja ich will es ja gerade umgedreht. Also ich hab jetzt "libapache2-mod-fcgid_2.1-2" KLICK im Einsatz. Mit dem 1.10 gabs schon wieder 500 er unter Last ... ok, kein Grund aufzugeben , oder besser gesagt sowas spornt mich eher an.

Nun hab ich ja in den Startern überall das i-bit. Da also was zu ändern ist ein wenig zeitaufwendiger, obwohls mit den passenden Scripts ja eigentlich auch gehen müsste.

Du sagst aber ich soll "-1" setzen, dann würde das "5000" er im Starter greifen. Hm, ok ich wil aber eigentlich "500" setzen, weil doch die "500 er" Error auch mit diesem Bug zusammenhängen können, der ja angeblich in den neuesten PHP Versionen 5.2+ und mod_fcgid ab 1.11 erledigt sein soll, allerdings nur mit der Angabe:

Code: Select all

MaxRequestsPerProcess 500 

Hintergrund zu Lesen wäre eventuell dieser Report: Klick

Doku

MaxRequestsPerProcess n (-1)

(Added in version 1.11, patch from Robert L Mathews)

Adds a MaxRequestsPerProcess parameter that allows mod_fcgid to exit after handling a certain number of requests, similar to the existing ProcessLifeTime option.

This solves a problem with PHP in FastCGI mode. By default, PHP stops accepting new FastCGI connections after handling 500 requests; unfortunately, there is a potential race condition during the PHP cleanup code in which PHP can be shutting down but still have the socket open, so mod_fcgid under heavy load can send request number 501 to PHP and have it "accepted", but then PHP appears to simply exit, causing errors.

If you are using PHP, you should set it to 500. -1 mean fastcgi process will not exit no matter how many requests it has handled.

Du sagst ja weiterhin, dass das niedrigste greift, das wäre ja in meinem Fall dann der "500" er Wert, um aber ganz sicher zu gehen, müsste ich wohl doch mit "sed" und einem script" bei tausenden Startern ein "#" vor die entsprechenden Code Zeilen machen .... ?

[kase]

Ich würde kein so niedriges Limit nehmen. Umso niedriger dein Limit, desto häufiger werden die Prozesse beendet, und desto häufiger kannst du unter Umständen ein 500er haben. Denn so lange kein Prozess stirbt, kann normalerweise auch nichts schiefgehen.

Du kannst dir dazu auch den langen Thread von TheOmega durchlesen, siehe SUFU.

[cirox]

Das ist natürlich immer dumm, wenn man mehrere Änderungen auf einmal durchführt. Es scheint fast so, als wenn die 500 er weniger geworden sind. Vorhin habe ich künslich Load erzeugt, indem ich nach 500 er n gegrept habe und "schwupps" war da wieder einer.

Ich werds beobachten mit den "MaxRequestsPerProcess"

Aber eins ist fast sicher. Die 500 er sind abhängig von:

- PHP Version
- mod_fcgid Version
- IPCConnectTimeout
- IPCCommTimeout
- BusyTimeout
- der LOAD des Rechners
- Anzahl der Childs
- MaxRequestsPerProcess