También tengo el mismo problema hace aproximadamente un año. Probé muchas cosas y, por último, realicé algunas de las cosas de golpe y ejecución después de leer la documentación y mi problema desapareció. Primero, las cosas importantes requeridas para establecerse como:
FcgidBusyTimeout 300 [default]
FcgidBusyScanInterval 120 [default]
El propósito de esta directiva es finalizar aplicaciones colgadas . Es posible que sea necesario aumentar el tiempo de espera predeterminado para las aplicaciones que pueden tardar más en procesar la solicitud. Porque la verificación se realiza en el intervalo definido por FcgidBusyScanInterval , se puede permitir que el manejo de solicitudes continúe por un período de tiempo más largo
FcgidProcessLifeTime 3600 [default]
Los procesos de aplicación inactivos que han existido durante más tiempo que este serán terminados, si el número de procesos para la clase excede FcgidMinProcessesPerClass .
Esta verificación de la vida útil del proceso se realiza con la frecuencia del FcgidIdleScanInterval configurado .
FcgidZombieScanInterval 3 [seconds default]
El módulo busca aplicaciones FastCGI cerradas en este intervalo. Durante este período de tiempo, la aplicación puede existir en la tabla de procesos como un zombi (en Unix).
Nota:todas las opciones anteriores disminuyen o aumentan según el tiempo o las necesidades del proceso de solicitud o se aplican a un host virtual específico.
Pero mi problema se resuelve con esta opción:
Las opciones anteriores han modificado mi servidor, pero después de un tiempo los errores parecen volver a aparecer, pero el error realmente se resuelve con esto:
FcgidOutputBufferSize 65536 [default]
Lo he cambiado a
FcgidOutputBufferSize 0
Esta es la cantidad máxima de datos de respuesta que el módulo leerá de la aplicación FastCGI antes de enviar los datos al cliente. Esto vaciará los datos al instante sin esperar a tener 64 KB de bytes, lo que realmente me ayuda a vaciar el proceso más rápido.
Otros problemas que tengo
si el error 500 proviene del tiempo de espera de Nginx. La solución:
/etc/nginx/nginx.conf
keepalive_timeout 125;
proxy_read_timeout 125;
proxy_connect_timeout 125;
fastcgi_read_timeout 125;
De forma intermitente obtenía el error MySQL "El servidor MySQL se ha ido", lo que requería una modificación más:/etc/my.conf
wait_timeout = 120
Luego, solo por diversión, seguí adelante y aumenté mi límite de memoria PHP, por si acaso:/etc/php.ini
memory_limit = 256M
Uso de SuExec
mod_fastcgi no funciona en absoluto bajo SuExec el Apache 2.x . No tuve más que problemas con eso (también tuvo muchos otros problemas en nuestras pruebas). La verdadera causa de su problema es SuExec
En mi caso, fue un inicio para mí, inicié Apache, mod_fcgid genera exactamente 5 procesos para cada vhost. Ahora, cuando se usa un script de carga simple y se envía un archivo de más de 4-8 KB, todos esos procesos secundarios se eliminan a la vez para el host virtual en el que se ejecutó el script.
Podría ser posible hacer una compilación de depuración o aumentar el registro en mod_fcgid, lo que podría dar una pista.
Mientras tanto, probé mod_fastcgi durante 1 año y también puedo decir con muchos otros que SuExec no es más que problemático y no funciona del todo bien, en todos los casos.
La advertencia no tiene nada que ver con ninguno de los Fcgidxxx opciones y simplemente se debe a que el cliente cierra su lado de la conexión antes de que el servidor tenga la oportunidad de responder.
De la fuente real:
/* 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;
}
El crédito es para el Blog de Avian que se enteró.