errori nginx "recv () non riuscito (104: connessione reimpostata dal peer) durante la lettura dell'intestazione della risposta dall'upstream"

Ho un server che funzionava bene fino al 3 ottobre 2013 alle 10:50 quando ha iniziato a restituire in modo intermittente errori "502 Bad Gateway" al client.

Circa 4 richieste su 5 su browser hanno esito positivo ma circa 1 su 5 ha esito negativo con un 502.

Il registro degli errori di nginx contiene molte centinaia di questi errori;

2013/10/05 06:28:17 [error] 3111#0: *54528 recv() failed (104: Connection reset by peer) while reading response header from upstream, client: 66.249.66.75, server: www.bec-components.co.uk  request: ""GET /?_n=Fridgefreezer/Hotpoint/8591P;_i=x8078 HTTP/1.1", upstream: "fastcgi://127.0.0.1:9000", host: "www.bec-components.co.uk"

Tuttavia, il registro errori PHP non contiene errori corrispondenti.

C'è un modo per ottenere PHP per darmi maggiori informazioni sul perché sta ripristinando la connessione?

Questo è nginx.conf;

user              www-data;
worker_processes  4;
error_log         /var/log/nginx/error.log;
pid               /var/run/nginx.pid;

events {
   worker_connections  1024;
}

http {
  include          /etc/nginx/mime.types;
  access_log       /var/log/nginx/access.log;

  sendfile               on;
  keepalive_timeout      30;
  tcp_nodelay            on;
  client_max_body_size   100m;

  gzip         on;
  gzip_types   text/plain application/xml text/javascript application/x-javascript text/css;
  gzip_disable "MSIE [1-6]\.(?!.*SV1)";

  include /gvol/sites/*/nginx.conf;

}

E questo è il .confper questo sito;

server {

  server_name   www.bec-components.co.uk bec3.uk.to bec4.uk.to bec.home;
  root          /gvol/sites/bec/www/;
  index         index.php index.html;

  location ~ \.(js|css|png|jpg|jpeg|gif|ico)$ {
    expires        2592000;   # 30 days
    log_not_found  off;
  }

  ## Trigger client to download instead of display '.xml' files.
  location ~ \.xml$ {
    add_header Content-disposition "attachment; filename=$1";
  }

   location ~ \.php$ {
      fastcgi_read_timeout  3600;
      include               /etc/nginx/fastcgi_params;
      keepalive_timeout     0;
      fastcgi_param         SCRIPT_FILENAME  $document_root$fastcgi_script_name;
      fastcgi_pass          127.0.0.1:9000;
      fastcgi_index         index.php;
   }
}

## bec-components.co.uk ##
server {
   server_name   bec-components.co.uk;
   rewrite       ^/(.*) http://www.bec-components.co.uk$1 permanent;
}

mi fiderei sempre se i miei server web mi dicessero: 502 Bad Gateway

• qual è il tempo di attività del processo fastcgi / nginx?
• monitorate le connessioni di rete?
• puoi confermare / negare un cambio di conteggio dei visitatori quel giorno?

cosa significa:

• il tuo processo fastcgi non è accessibile da nginx; rallentare o non corrispondere affatto. cattivo gateway significa: nginx non può fastcgi_pass a quella risorsa definita 127.0.0.1:9000; in quel preciso momento .

• i tuoi log degli errori iniziali dicono tutto:

.

recv() failed 
    -> nginx failed

(104: Connection reset by peer) while reading response header from upstream, 
    -> no complete answer, or no answer at all
upstream: "fastcgi://127.0.0.1:9000", 
    -> who is he, who failed???

dal mio pov limitato suggerirei:

• riavvia il tuo fastcgi_process / server
• controlla il tuo registro di accesso
• abilita debug-log

So che questo argomento è vecchio, ma continua a comparire di tanto in tanto, quindi, cercando risposte sul web, ho trovato le seguenti tre possibilità:

1. A volte un errore di programmazione segfault php-fpm, che a sua volta significa che la connessione con nginx verrà interrotta. Questo di solito lascerà almeno alcuni log in giro e / o core dump, che possono essere analizzati ulteriormente.
2. Per qualche motivo, PHP non è in grado di scrivere un file di sessione (di solito:) session.save_path = "/var/lib/php/sessions". Questo può essere un cattivo permesso, una cattiva proprietà, un cattivo utente / gruppo o problemi più esoterici / oscuri come l'esaurimento degli inode su quella directory (o persino un disco intero!). Questo di solito non lascerà in giro molti dump core e forse nemmeno nulla nei log degli errori di PHP.
3. Ancora più difficile da eseguire il debug: un'estensione si comporta male (colpendo occasionalmente una sorta di limite interno, o un bug che non viene sempre attivato), segfaulting e portando con sé il processo php-fpm - chiudendo così la connessione con nginx . I soliti colpevoli sono APC, memcache / d, ecc. (Nel mio caso era l'estensione New Relic), quindi l'idea qui è di disattivare ogni estensione fino a quando l'errore scompare.

Ho continuato a ottenere anche questo. Risolto aumentando il opcachelimite di memoria, se lo si utilizza (sostituzione per APC). Sembra che PHP-FPM abbia abbandonato le connessioni ogni volta che la cache era troppo piena. Questo è anche il motivo per cui la risposta di shgnInc la risolve per un breve periodo.

Quindi trova il file /etc/php5/fpm/php.ini(o equivalente nella tua distribuzione) e aumenta memory_consumptiona qualsiasi livello di cui il tuo sito ha bisogno. Anche la disabilitazione opcachepuò funzionare.

[opcache]
opcache.memory_consumption = 196 

Potresti voler considerare questo git su github: https://gist.github.com/amichaelgrant/90d99d7d5d48bf8fd209

Ho riscontrato una situazione simile, quando ho controllato i log degli errori per i miei server upstream, stavano segnalando un errore ulimit, quindi l'ho aumentato a 1000000 (su entrambi i riquadri upstream e nginx) e tutto ha funzionato bene

Nel mio caso di stesso problema, ho appena riavviato il php-fpmservizio in modo che sia risolto.

sudo service php5-fpm restart

O alcune volte questo problema si verifica a causa di enormi richieste. Di default pm.max_requestsin php5-fpm forse è 100 o inferiore.

Per risolverlo aumentare il suo valore dipende dalle richieste del tuo sito, ad esempio 500.

E dopo devi riavviare il servizio

Nel mio caso, disabilitare l' estensione xdebug ha aiutato.

Ho appena avuto un problema simile:

Ti connetti a php-fpm sulla porta 9000. (fastcgi: //127.0.0.1: 9000)

La configurazione standard su Ubuntu sul mio server è:

/etc/php/7.0/fpm/pool.d/www.conf:

listen = /run/php/php7.0-fpm.sock

devi cambiarlo in:

listen = 0.0.0.0:9000

Nel mio caso, ho aggiornato il mio server 1 1/2 mese fa, sovrascrivendo la mia configurazione costom con l'impostazione predefinita. Dopo aver riavviato php-fpm questo errore ha avuto effetto con ritardo.

Per me è stato il server che ha esaurito la memoria e php-fpm è stato ucciso dal killer OOM. La soluzione era aumentare la quantità di memoria del server.

Per me è stato perché php-fpm stava raggiungendo il max_childrenlimite. Il registro php-fpm per il pool in questione mi ha indicato la giusta direzione

Questo problema può verificarsi anche se un processo PHP-FPM supera il limite di memoria allocata. Quando ciò accade, la connessione tra NGINX e PHP-FPM viene interrotta e NGINX restituisce a 502 Bad Gateway. Il limite della memoria di processo PHP-FPM è controllato dalla memory_limitvariabile. Questo può essere impostato con php_admin_value[memory_limit]nel file di configurazione PHP-FPM.

È importante notare che il limite di memoria si applica in base allo script . Con i nprocessi PHP-FPM, l'utilizzo totale della memoria può essere fino a memory_limit * n. Assicurati di controllare che la tua macchina abbia spazio di memoria sufficiente!