J'ai également le même problème il y a environ un an, j'ai essayé beaucoup de choses et en dernier, j'ai fait certaines des choses éclair après avoir lu la documentation et mon problème a disparu. Tout d'abord, les éléments importants doivent être définis comme :
FcgidBusyTimeout 300 [default]
FcgidBusyScanInterval 120 [default]
Le but de cette directive est de mettre fin aux applications bloquées . Le délai d'attente par défaut peut devoir être augmenté pour les applications qui peuvent prendre plus de temps pour traiter la demande. Parce que la vérification est effectuée à l'intervalle défini par FcgidBusyScanInterval , le traitement des demandes peut être autorisé à se poursuivre pendant une période plus longue
FcgidProcessLifeTime 3600 [default]
Les processus d'application inactifs qui existent depuis plus longtemps que cette durée seront terminés si le nombre de processus pour la classe dépasse FcgidMinProcessesPerClass .
Cette vérification de la durée de vie du processus est effectuée à la fréquence du FcgidIdleScanInterval configuré .
FcgidZombieScanInterval 3 [seconds default]
Le module vérifie les applications FastCGI fermées à cet intervalle. Pendant cette période, l'application peut exister dans la table de processus en tant que zombie (sous Unix).
Remarque :Toutes les options ci-dessus diminuent ou augmentent en fonction du temps de traitement de votre demande ou de vos besoins ou s'appliquent à un vhost spécifique.
Mais mon problème est résolu par cette option :
Les options ci-dessus ont modifié mon serveur, mais après un certain temps, les erreurs semblent revenir, mais l'erreur est vraiment résolue par ceci :
FcgidOutputBufferSize 65536 [default]
Je l'ai changé en
FcgidOutputBufferSize 0
Il s'agit de la quantité maximale de données de réponse que le module lira depuis l'application FastCGI avant de vider les données vers le client. Cela va vider les données instantanément sans attendre d'avoir 64 Ko d'octets, ce qui m'aide vraiment à vider le processus plus rapidement.
Autres problèmes rencontrés
si 500 Erreur provenant du délai d'expiration de Nginx. Le correctif :
/etc/nginx/nginx.conf
keepalive_timeout 125;
proxy_read_timeout 125;
proxy_connect_timeout 125;
fastcgi_read_timeout 125;
Par intermittence, j'obtenais l'erreur MySQL "Le serveur MySQL est parti", ce qui nécessitait un ajustement supplémentaire :/etc/my.conf
wait_timeout = 120
Ensuite, juste pour le plaisir, j'ai augmenté ma limite de mémoire PHP, juste au cas où :/etc/php.ini
memory_limit = 256M
Utiliser SuExec
mod_fastcgi ne fonctionne pas du tout sous SuExec le Apache 2.x . Je n'ai eu que des problèmes à cause de cela (il a également eu de nombreux autres problèmes lors de nos tests). La véritable cause de votre problème est SuExec
Dans mon cas, c'était une startup pour moi, j'ai démarré Apache, mod_fcgid génère exactement 5 processus pour chaque vhost. Désormais, lors de l'utilisation d'un simple script de téléchargement et de la soumission d'un fichier de plus de 4 à 8 Ko, tous ces processus enfants sont tués en même temps pour le vhost spécifique sur lequel le script a été exécuté.
Il pourrait être possible de créer une version de débogage ou d'augmenter la journalisation dans mod_fcgid, ce qui pourrait donner un indice.
J'ai essayé mod_fastcgi entre-temps pendant 1 an et moi aussi je peux dire avec beaucoup d'autres que SuExec n'est que gênant et ne fonctionne pas du tout correctement, dans tous les cas.
L'avertissement n'a rien à voir avec l'un des Fcgidxxx options et est simplement causé par le fait que le client ferme son côté de la connexion avant que le serveur n'ait eu la chance de répondre.
À partir de la source réelle :
/* 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;
}
Le mérite revient au blog d'Avian qui l'a découvert.