Sto anche riscontrando lo stesso problema circa un anno fa, quindi ho provato molte cose e alla fine ho fatto alcune delle cose mordi e fuggi dopo aver letto la documentazione e il mio problema è scomparso. Prima le cose importanti che devono essere impostate come:
FcgidBusyTimeout 300 [default]
FcgidBusyScanInterval 120 [default]
Lo scopo di questa direttiva è di terminare le applicazioni bloccate . Potrebbe essere necessario aumentare il timeout predefinito per le applicazioni che impiegano più tempo per elaborare la richiesta. Perché il controllo viene eseguito all'intervallo definito da FcgidBusyScanInterval , la gestione della richiesta può essere consentita per un periodo di tempo più lungo
FcgidProcessLifeTime 3600 [default]
I processi applicativi inattivi che sono esistiti da più di questo tempo verranno terminati se il numero di processi per la classe supera FcgidMinProcessesPerClass .
Questo controllo della durata del processo viene eseguito alla frequenza del FcgidIdleScanInterval configurato .
FcgidZombieScanInterval 3 [seconds default]
Il modulo controlla le applicazioni FastCGI terminate a questo intervallo. Durante questo periodo di tempo, l'applicazione può esistere nella tabella dei processi come zombie (su Unix).
Nota:tutte le opzioni precedenti diminuiscono o aumentano in base al tempo o alle esigenze del processo di candidatura o si applicano a un vhost specifico.
Ma il mio problema si risolve con questa opzione:
Le opzioni di cui sopra hanno ottimizzato il mio server ma dopo qualche tempo gli errori sembrano ripresentarsi ma l'errore è davvero risolto da questo:
FcgidOutputBufferSize 65536 [default]
L'ho cambiato in
FcgidOutputBufferSize 0
Questa è la quantità massima di dati di risposta che il modulo leggerà dall'applicazione FastCGI prima di trasferire i dati al client. Questo cancellerà istantaneamente i dati senza aspettare di avere 64 KB di byte, il che mi aiuta davvero a svuotare il processo più velocemente.
Altri problemi che ho riscontrato
se 500 Errore proveniente dal timeout di Nginx. La soluzione:
/etc/nginx/nginx.conf
keepalive_timeout 125;
proxy_read_timeout 125;
proxy_connect_timeout 125;
fastcgi_read_timeout 125;
A intermittenza ricevevo l'errore MySQL "Il server MySQL è andato via", che richiedeva un'altra modifica:/etc/my.conf
wait_timeout = 120
Quindi, solo per divertimento, sono andato avanti e ho aumentato il mio limite di memoria PHP, per ogni evenienza:/etc/php.ini
memory_limit = 256M
Utilizzo di SuExec
mod_fastcgi non funziona affatto sotto SuExec su Apache 2.x . Non ho avuto altro che problemi (ha avuto anche numerosi altri problemi nei nostri test). La vera causa del tuo problema è SuExec
Nel mio caso è stata una startup per me, ho avviato Apache, mod_fcgid genera esattamente 5 processi per ogni vhost. Ora, quando si utilizza un semplice script di caricamento e si invia un file più grande di 4-8 KB, tutti quei processi figlio vengono interrotti contemporaneamente per il vhost specifico su cui è stato eseguito lo script.
Potrebbe essere possibile creare build di debug o avviare il log in mod_fcgid che potrebbe fornire un indizio.
Nel frattempo ho provato mod_fastcgi per 1 anno e anch'io posso dire con molti altri che SuExec non è altro che fastidioso e non funziona affatto bene, in ogni caso.
L'avviso non ha nulla a che fare con nessuno dei Fcgidxxx opzioni ed è semplicemente causato dalla chiusura del lato della connessione da parte del client prima che il server abbia la possibilità di rispondere.
Dalla fonte effettiva:
/* 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;
}
Il merito va al blog di Avian che lo ha scoperto.