kesalahan nginx “recv () gagal (104: Koneksi reset oleh rekan) saat membaca header respons dari hulu”

Saya memiliki server yang berfungsi dengan baik hingga 3 Oktober 2013 pukul 10:50 ketika server mulai mengembalikan kesalahan "502 Bad Gateway" sebentar-sebentar ke klien.

Sekitar 4 dari 5 permintaan browser berhasil tetapi sekitar 1 dari 5 gagal dengan 502.

Log kesalahan nginx berisi ratusan kesalahan ini;

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"

Namun log kesalahan PHP tidak mengandung kesalahan yang cocok.

Apakah ada cara untuk mendapatkan PHP untuk memberi saya lebih banyak info tentang mengapa pengaturan ulang koneksi?

Ini adalah 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;

}

Dan ini .confuntuk situs ini;

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;
}

saya selalu percaya jika pelayan web saya memberi tahu saya: 502 Bad Gateway

• apa uptime proses fastcgi / nginx Anda?
• Anda memonitor koneksi jaringan?
• dapatkah Anda mengonfirmasi / menolak perubahan jumlah pengunjung sekitar hari itu?

apa artinya:

• Anda proses fastcgi tidak dapat diakses oleh nginx; baik untuk memperlambat atau tidak sesuai sama sekali. gateway buruk berarti: nginx tidak dapat fastcgi_pass ke ressource yang ditentukan 127.0.0.1:9000; pada saat yang sangat spesifik .

• log kesalahan awal Anda memberitahukan semuanya:

.

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???

dari pov terbatas saya, saya sarankan:

• mulai ulang fastcgi_process / server Anda
• periksa log akses Anda
• aktifkan debug-log

Saya tahu topik ini sudah lama, tetapi masih terus muncul sesekali, jadi, mencari jawaban di web, saya menemukan tiga kemungkinan berikut:

1. Kesalahan pemrograman terkadang memisahkan php-fpm, yang pada gilirannya berarti koneksi dengan nginx akan terputus. Ini biasanya akan meninggalkan setidaknya beberapa log di sekitar dan / atau dump inti, yang dapat dianalisis lebih lanjut.
2. Untuk beberapa alasan, PHP tidak dapat menulis file sesi (biasanya session.save_path = "/var/lib/php/sessions":). Ini bisa berupa izin buruk, kepemilikan buruk, pengguna / grup buruk, atau masalah esoteris / tidak jelas lainnya seperti kehabisan inode pada direktori tersebut (atau bahkan disk lengkap!). Ini biasanya tidak akan meninggalkan banyak dump inti dan bahkan mungkin tidak ada apa-apa pada log kesalahan PHP.
3. Yang lebih sulit untuk di-debug: ekstensi salah tingkah (kadang-kadang memukul semacam batasan dalam, atau bug yang tidak terpicu sepanjang waktu), melakukan segmentasi, dan membawa proses php-fpm turun bersamanya - sehingga menutup koneksi dengan nginx . Penyebab umum adalah APC, memcache / d, dll. (Dalam kasus saya itu adalah ekstensi Relic Baru), jadi ide di sini adalah untuk mematikan setiap ekstensi sampai kesalahan hilang.

Tetap dapatkan ini juga. Mengatasinya dengan meningkatkan opcachebatas memori, jika Anda menggunakannya (pengganti APC). Tampaknya PHP-FPM menjatuhkan koneksi setiap kali cache terlalu penuh. Ini juga alasan mengapa jawaban shgnInc memperbaikinya untuk waktu yang singkat.

Jadi temukan file /etc/php5/fpm/php.ini(atau setara dalam distribusi Anda) dan tingkatkan memory_consumptionke tingkat apa pun yang dibutuhkan situs Anda. Menonaktifkan opcachejuga dapat bekerja.

[opcache]
opcache.memory_consumption = 196 

Anda mungkin ingin mempertimbangkan git ini di github: https://gist.github.com/amichaelgrant/90d99d7d5d48bf8fd209

Saya mengalami situasi yang sama, ketika saya memeriksa log kesalahan untuk server hulu saya mereka melaporkan beberapa kesalahan ulimit jadi saya meningkatkannya menjadi 10.00000 (pada kotak hulu dan nginx) dan semuanya bekerja dengan baik

Dalam kasus masalah yang sama, saya hanya me-restart php-fpmlayanan sehingga diselesaikan.

sudo service php5-fpm restart

Atau beberapa kali masalah ini terjadi karena banyaknya permintaan. Secara default di pm.max_requestsdalam php5-fpm mungkin 100 atau di bawah.

Untuk mengatasinya, kenaikan nilainya tergantung pada permintaan situs Anda, Misalnya 500.

Dan setelah itu Anda harus me-restart layanan

Dalam kasus saya, menonaktifkan ekstensi xdebug memang membantu.

Saya hanya punya masalah serupa:

Anda terhubung ke php-fpm di Port 9000. (fastcgi: //127.0.0.1: 9000)

Konfigurasi standar pada Ubuntu di server saya adalah:

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

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

Anda harus mengubahnya ke:

listen = 0.0.0.0:9000

Dalam kasus saya, saya memperbarui server saya 1 1/2 Bulan yang lalu, menimpa konfigurasi costom saya dengan default. Sekarang setelah restart php-fpm kesalahan ini mulai berlaku dengan penundaan.

Bagi saya itu adalah server kehabisan memori dan php-fpm terbunuh oleh pembunuh OOM. Solusinya adalah meningkatkan jumlah memori server.

Bagi saya itu karena php-fpm telah mencapai max_childrenbatasnya. Log php-fpm untuk pool yang dimaksud mengarahkan saya ke arah yang benar

Masalah ini juga dapat muncul jika proses PHP-FPM melebihi batas memori yang dialokasikan. Ketika ini terjadi, koneksi antara NGINX dan PHP-FPM terputus dan NGINX mengembalikan a 502 Bad Gateway. Batas memori proses PHP-FPM dikendalikan oleh memory_limitvariabel. Ini dapat diatur dengan php_admin_value[memory_limit]dalam file konfigurasi PHP-FPM.

Penting untuk dicatat bahwa batas memori berlaku berdasarkan per-skrip . Dengan nproses PHP-FPM, total penggunaan memori bisa maksimal memory_limit * n. Pastikan untuk memeriksa bahwa mesin Anda memiliki ruang memori yang cukup!