nginx hataları “recv () başarısız oldu (104: Yanıt başlığını yukarı akıştan okurken).

"502 Bad Gateway" hatalarını istemciye zaman zaman döndürmeye başladığında, 10 Ekim 2013 günü saat 10: 50'de tamamıyla çalışan bir sunucum var.

Yaklaşık 5 tarayıcı talebinden yaklaşık 4'ü başarılı oluyor, ancak yaklaşık 5'i bir 502 ile başarısız oluyor.

Nginx hata günlüğü bu hatalardan yüzlerce içerir;

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"

Ancak, PHP hata günlüğü herhangi bir eşleşen hata içermiyor.

PHP'nin bağlantıyı neden sıfırladığı hakkında daha fazla bilgi vermesinin bir yolu var mı?

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

}

Ve bu, .confbu site içindir;

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

webserversim bana anlatırsa hep güvenirim: 502 Bad Gateway

• fastcgi / nginx - işleminizin çalışma süresi nedir?
• ağ bağlantılarını izliyor musunuz?
• o günkü ziyaretçi sayısındaki değişikliği onaylayabilir / reddedebilir misiniz?

bunun anlamı ne:

• fastcgi işlemine nginx tarafından erişilemiyor; Yavaş ya da hiç karşılık gelmiyor. hatalı ağ geçidi şu anlama gelir: nginx, 127.0.0.1:9000; tam da o anda .

• inital hata günlükleriniz hepsini anlatıyor:

.

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

benim sınırlı pov dan öneririm:

• fastcgi_process / sunucunuzu yeniden başlatın
• erişim günlüğünü kontrol et
• hata ayıklama günlüğünü etkinleştir

Bu konunun eski olduğunu biliyorum, ancak ara sıra hala ortaya çıkmaya devam ediyor, bu yüzden, web üzerinden cevaplar ararken şu üç olasılıkla karşılaştım:

1. Bir programlama hatası bazen php-fpm'yi keser, bu da nginx ile bağlantının kopacağı anlamına gelir. Bu genellikle daha sonra analiz edilebilecek en azından bazı kütükler ve / veya çekirdek dökümleri bırakacaktır.
2. Bazı nedenlerden dolayı, PHP bir oturum dosyası yazamamaktadır (genellikle:) session.save_path = "/var/lib/php/sessions". Bu, kötü izinler, kötü sahiplik, kötü kullanıcı / grup veya o dizindeki düğümlerin tükenmesi gibi daha ezoterik / belirsiz sorunlar olabilir (hatta tam bir disk!) Bu genellikle olacak değil birçok çekirdek muhtemelen PHP hata günlükleri bile bir şey etrafında döker ve bırakın.
3. Hata ayıklamak daha da zor: bir uzantı hatalı çalışıyor (zaman zaman bir tür iç sınırlamaya veya her zaman tetiklenmeyen bir hataya çarpıyor), segfaulting ve php-fpm işlemini bununla aşağıya çekiyor - böylelikle bağlantıyı nginx ile kapatmak . Olağan suçlular APC, memcache / d, vs.'dir (benim durumumda Yeni Relic uzantısıydı), bu yüzden burada fikir, hata ortadan kalkıncaya kadar her bir uzantıyı kapatmaktır.

Bunu da aldım. Kullanıyorsanız, opcachehafıza sınırını artırarak çözüldü (APC için değiştirme). Önbellek çok dolduğunda PHP-FPM'in bağlantıları bıraktığı görülüyor. Bu aynı zamanda shgnInc'in cevabını kısa bir süre için düzelmesinin de nedenidir.

Bu nedenle dosyayı bulun /etc/php5/fpm/php.ini(veya dağıtımınızdaki eşdeğeri) ve memory_consumptionsitenizin ihtiyaç duyduğu seviyeye yükseltin . Devre dışı bırakmak opcacheda işe yarayabilir.

[opcache]
opcache.memory_consumption = 196 

Bunu github'da düşünebilirsiniz: https://gist.github.com/amichaelgrant/90d99d7d5d48bf8fd209

Benzer bir durumla karşılaştım, yukarı akış sunucularım için hata günlüklerini kontrol ettiğimde bazı ulimit hatalarını rapor ediyorlardı, bu yüzden bunu 1000000'e (hem yukarı hem de nginx kutularında) yükselttim ve her şey yolunda gitti

Aynı problemde, ben sadece php-fpmservisi yeniden başlattım, böylece çözüldü.

sudo service php5-fpm restart

Ya da bazı zamanlar bu sorun çok fazla istek yüzünden olur. Varsayılan pm.max_requestsolarak php5-fpm'de belki 100 veya altındadır.

Bunun değerini artırmak için sitenizin isteklerine bağlı olarak, örneğin 500.

Ve sizden sonra servisi yeniden başlatmanız gerekecek.

Benim durumumda, xdebug eklentisini devre dışı bırakmak yardımcı oldu.

Ben de benzer bir problem yaşadım:

Php-fpm'ye Port 9000'den bağlanırsınız. (Fastcgi: //127.0.0.1: 9000)

Sunucumdaki Ubuntu'da standart yapılandırma:

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

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

Bunu şu şekilde değiştirmelisin:

listen = 0.0.0.0:9000

Benim durumumda, sunucumu 1 1/2 ay önce, costom konfigürasyonumun üzerine varsayılan olarak yazdım. Şimdi php-fpm'yi yeniden başlattıktan sonra bu hata gecikmeyle sonuçlandı.

Benim için sunucunun hafızası tükendi ve php-fpm, OOM katili tarafından öldürüldü. Çözüm, sunucu belleği miktarını artırmaktı.

Benim için çünkü php-fpm max_childrensınırını zorluyordu . Söz konusu havuz için php-fpm kütüğü bana doğru yöne işaret etti

Bu sorun ayrıca bir PHP-FPM işlemi ayrılan bellek sınırını aşarsa da ortaya çıkabilir. Bu olduğunda, NGINX ve PHP-FPM arasındaki bağlantı kopar ve NGINX a döndürür 502 Bad Gateway. PHP-FPM işlem hafıza sınırı memory_limitdeğişken tarafından kontrol edilir . Bu php_admin_value[memory_limit], PHP-FPM yapılandırma dosyasında ayarlanabilir.

Bellek sınırının her komut dosyası için geçerli olduğunu not etmek önemlidir . İle nPHP-FPM süreçler, toplam bellek kullanımı kadar olabilir memory_limit * n. Makinenizde yeterli bellek boşluğu olduğundan emin olun!