Ich habe auch das gleiche Problem vor etwa einem Jahr, damals habe ich viele Dinge ausprobiert und zuletzt habe ich einige der Hit-and-Run-Dinge nach dem Lesen der Dokumentation erledigt und mein Problem ist weg. Zuerst müssen die wichtigen Dinge wie folgt eingestellt werden:
FcgidBusyTimeout 300 [default]
FcgidBusyScanInterval 120 [default]
Der Zweck dieser Anweisung ist es, hängende Anwendungen zu beenden . Das Standard-Timeout muss möglicherweise für Anwendungen erhöht werden, die länger brauchen, um die Anfrage zu verarbeiten. Denn die Überprüfung erfolgt in dem durch FcgidBusyScanInterval definierten Intervall , kann die Bearbeitung von Anfragen für einen längeren Zeitraum fortgesetzt werden
FcgidProcessLifeTime 3600 [default]
Leerlaufanwendungsprozesse, die länger als diese Zeit existieren, werden beendet, wenn die Anzahl der Prozesse für die Klasse FcgidMinProcessesPerClass überschreitet .
Diese Überprüfung der Prozesslebensdauer wird mit der Häufigkeit des konfigurierten FcgidIdleScanInterval durchgeführt .
FcgidZombieScanInterval 3 [seconds default]
Das Modul sucht in diesem Intervall nach beendeten FastCGI-Anwendungen. Während dieser Zeit kann die Anwendung in der Prozesstabelle als Zombie (unter Unix) existieren.
Hinweis:Alle oben genannten Optionen verringern oder erhöhen sich entsprechend Ihrer Bewerbungsprozesszeit oder Ihren Anforderungen oder gelten für einen bestimmten vhost.
Aber mein Problem wird durch diese Option gelöst:
Die obigen Optionen haben meinen Server optimiert, aber nach einiger Zeit scheinen die Fehler wieder zu kommen, aber der Fehler wird wirklich dadurch behoben:
FcgidOutputBufferSize 65536 [default]
Ich habe es in
geändert FcgidOutputBufferSize 0
Dies ist die maximale Menge an Antwortdaten, die das Modul von der FastCGI-Anwendung liest, bevor die Daten an den Client übertragen werden. Dadurch werden die Daten sofort geleert, ohne darauf zu warten, 64 KB Bytes zu haben, was mir wirklich hilft, den Prozess schneller zu leeren.
Andere Probleme, die ich habe
wenn 500-Fehler von Nginx-Zeitüberschreitung kommt. Die Lösung:
/etc/nginx/nginx.conf
keepalive_timeout 125;
proxy_read_timeout 125;
proxy_connect_timeout 125;
fastcgi_read_timeout 125;
Gelegentlich erhielt ich den MySQL-Fehler „MySQL-Server ist verschwunden“, was eine weitere Optimierung erforderte:/etc/my.conf
wait_timeout = 120
Dann, nur aus Spaß, habe ich mein PHP-Speicherlimit erhöht, nur für den Fall:/etc/php.ini
memory_limit = 256M
SuExec verwenden
mod_fastcgi funktioniert überhaupt nicht unter SuExec auf Apache 2.x . Ich hatte nichts als Probleme damit (es hatte auch zahlreiche andere Probleme in unseren Tests). Die eigentliche Ursache Ihres Problems ist SuExec
In meinem Fall war das ein Startup für mich, ich starte Apache, mod_fcgid erzeugt genau 5 Prozesse für jeden vhost. Wenn Sie jetzt ein einfaches Upload-Skript verwenden und eine Datei mit mehr als 4-8 KB senden, werden alle diese untergeordneten Prozesse auf einmal für den spezifischen vhost beendet, auf dem das Skript ausgeführt wurde.
Es könnte möglich sein, einen Debug-Build zu erstellen oder die Protokollierung in mod_fcgid anzukurbeln, was einen Hinweis geben könnte.
Ich habe mod_fastcgi inzwischen 1 Jahr ausprobiert und kann auch mit vielen anderen sagen, dass SuExec nur lästig ist und überhaupt nicht rund läuft, in jedem Fall.
Die Warnung hat nichts mit Fcgidxxx zu tun Optionen und wird einfach dadurch verursacht, dass der Client seine Seite der Verbindung schließt, bevor der Server antworten kann.
Aus der eigentlichen Quelle:
/* Now pass any remaining response body data to output filters */
if ((rv = ap_pass_brigade(r->output_filters, brigade_stdout)) != APR_SUCCESS) {
if (!APR_STATUS_IS_ECONNABORTED(rv)) {
ap_log_rerror(APLOG_MARK, APLOG_WARNING, rv, r,
"mod_fcgid: ap_pass_brigade failed in "
"handle_request_ipc function");
}
return HTTP_INTERNAL_SERVER_ERROR;
}
Dank geht an Avians Blog, der davon erfahren hat.