Dette problem er generelt ikke kun værtsspecifikt, det er også udviklerrelateret, afhængigt af konfigurationen. Nogle værter er dog ret strenge med FastCGI og vil begrænse dine muligheder. Det er generelt nemmere at køre uden at bruge FastCGI og bare bruge mod_php, medmindre du har et specifikt behov for at bruge FastCGI i din applikation.
Vi bliver nødt til at se din fcgi-indpakning (hvad der er i /dev/shm/blackmou-php.fcgi) eller .htaccess for FastCGI spawning, for bedre at kunne hjælpe dig uden at vide, hvilke filer og koden, der er på disse filer, problemet opstår med. Bruger dine værter også Apache, LightHttpd eller Nginx (eller kombination)? På det tidspunkt foreslår jeg kraftigt at opdatere til PHP 5.3.9+
Da dette kan være forårsaget af et vilkårligt antal problemer, forhindrer FastCGI effektivt dit websted/dit scripts i at blive angrebet af et Denial of Service eller at gå ned på grund af hukommelseslækager osv. (F.eks.:forsøger at håndtere 80.000 forbindelser blot ved at droppe og begrænse antallet af anmodninger eller sidde fast i en endeløs løkke ved at time-out og afslutte processen)
Denne fejl er især forårsaget af en idle_timeout (30 sekunder som standard) eller maks. børneprocesgrænse. Den kan også være forårsaget af, at nogen starter et langvarigt script og lukker deres browser/forbindelse, før scriptet er færdigt.
FastCGI starter sin procesindpakning, udfører en kommando, timeout før fuldførelse af processen, forbindelsen ses som nulstillet af peer.
Et andet eksempel er, at det maksimale antal børn (maxProcesses) er nået (f.eks.:mange websteder viser 2 eller 4 som et eksempel, når du i virkeligheden har brug for 20 eller 50 afhængigt af gennemsnitlig trafik) Hvis alle børn i øjeblikket er aktive og en yderligere anmodning/ forbindelsen er oprettet, er børnene begrænset til maxProcesses, som FastCGI ikke deler de aktive børn til, så det skal først enten afslutte processen og starte en ny underordnet proces eller droppe anmodningen, afhængigt af dine konfigurationer.
Her er nogle flere oplysninger om indstillingerne:
http://www.fastcgi.com/mod_fastcgi/docs/mod_fastcgi.html
http://www.fastcgi.com/drupal/node/10
Indpakningseksempel
PHP_FCGI_CHILDREN=0 #no limit
export PHP_FCGI_CHILDREN
PHP_FCGI_MAX_REQUESTS=10000
export PHP_FCGI_MAX_REQUESTS
OPDATERING
For at tilføje dette, kan dette også være forårsaget af php-hukommelsesgrænse
Hvis ovenstående ikke løser dit problem, skal du opdatere din php.ini for at øge memory_limit