Mám také stejný problém asi před rokem, pak jsem zkoušel mnoho věcí a nakonec jsem po přečtení dokumentace udělal některé věci s hitem a spuštěním a můj problém je pryč. Nejprve důležité věci, které je třeba nastavit jako:
FcgidBusyTimeout 300 [default]
FcgidBusyScanInterval 120 [default]
Účelem této směrnice je ukončit zavěšené aplikace . Výchozí časový limit může být nutné zvýšit u aplikací, kterým může zpracování požadavku trvat déle. Protože kontrola se provádí v intervalu definovaném FcgidBusyScanInterval , může být povoleno vyřizování žádostí pokračovat po delší dobu
FcgidProcessLifeTime 3600 [default]
Nečinné aplikační procesy, které existují déle než tuto dobu, budou ukončeny, pokud počet procesů pro třídu překročí FcgidMinProcessesPerClass .
Tato kontrola životnosti procesu se provádí s frekvencí nakonfigurovaných FcgidIdleScanInterval .
FcgidZombieScanInterval 3 [seconds default]
Modul v tomto intervalu kontroluje ukončené aplikace FastCGI. Během této doby může aplikace existovat v tabulce procesů jako zombie (v Unixu).
Poznámka:Všechny výše uvedené možnosti Snížit nebo zvýšit podle času nebo potřeb vaší aplikace nebo použít pro konkrétní vhost.
Ale můj problém vyřeší tato možnost:
Výše uvedené možnosti vylepšily můj server, ale po nějaké době se zdá, že se chyby znovu objevují, ale chyba je skutečně vyřešena tímto:
FcgidOutputBufferSize 65536 [default]
Změnil jsem to na
FcgidOutputBufferSize 0
Toto je maximální množství dat odezvy, které modul načte z aplikace FastCGI, než data vyprázdní do klienta. Tím se data okamžitě vyprázdní a nebudou čekat na 64 kB bajtů, což mi opravdu pomáhá rychleji vyprázdnit proces.
Další problémy
pokud vypršel časový limit 500 přicházející z Nginx. Oprava:
/etc/nginx/nginx.conf
keepalive_timeout 125;
proxy_read_timeout 125;
proxy_connect_timeout 125;
fastcgi_read_timeout 125;
Občas se mi zobrazila chyba MySQL „Server MySQL zmizel“, což vyžadovalo ještě jedno vylepšení:/etc/my.conf
wait_timeout = 120
Pak jsem jen pro legraci pokračoval a pro jistotu jsem zvýšil limit paměti PHP:/etc/php.ini
memory_limit = 256M
Použití SuExec
mod_fastcgi pod SuExec vůbec nefunguje na Apache 2.x . Neměl jsem s tím nic jiného než potíže (při našem testování to také mělo řadu dalších problémů). Skutečnou příčinou vašeho problému je SuExec
V mém případě to pro mě bylo spuštění, spustím Apache, mod_fcgid vytvoří přesně 5 procesů pro každého vhost. Nyní, při použití jednoduchého skriptu pro nahrávání a odeslání souboru většího než 4–8 kB, jsou všechny tyto podřízené procesy najednou zabity pro konkrétní vhost, na kterém byl skript spuštěn.
Mohlo by být možné vytvořit sestavení ladění nebo nastartovat přihlašování v mod_fcgid, což by mohlo napovědět.
Mezitím jsem zkoušel mod_fastcgi po dobu 1 roku a také mohu s mnoha dalšími říci, že SuExec není nic jiného než problémový a v každém případě neběží vůbec hladce.
Varování nemá nic společného s Fcgidxxx volby a je jednoduše způsobena tím, že klient uzavře svou stranu připojení dříve, než server dostane příležitost odpovědět.
Ze skutečného zdroje:
/* 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;
}
Poděkování patří Avian's Blog, který se o tom dozvěděl.