अपस्ट्रीम से प्रतिक्रिया हेडर पढ़ते समय nginx त्रुटियां "पुनरावृत्ति () विफल (104: सहकर्मी द्वारा कनेक्शन रीसेट)"

Question

मेरे पास एक सर्वर है जो 3 अक्टूबर 2013 को प्रातः 10:50 बजे तक ठीक काम कर रहा था जब ग्राहक को "502 बैड गेटवे" त्रुटियां देना शुरू हुआ।

5 ब्राउज़र अनुरोधों में से लगभग 4 सफल होते हैं, लेकिन 5 में से 1 502 के साथ विफल हो जाता है।

नेगनेक्स त्रुटि लॉग में इनमें से कई सैकड़ों त्रुटियां हैं;

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"

हालाँकि PHP त्रुटि लॉग में कोई भी मिलान त्रुटि नहीं है।

क्या मुझे कनेक्शन रीसेट करने के बारे में अधिक जानकारी देने के लिए PHP प्राप्त करने का एक तरीका है?

यह है 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;

}

और यह .confइस साइट के लिए है;

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

Comments

उस दिन क्या बदला था? अपने आवेदन या PHP अद्यतन? आपका आवेदन क्या है? क्या आपने php-fpm में डिबगिंग सक्षम किया है?

— पोथी कालीमुथु

उस दिन कुछ भी नहीं बदला था। सर्वर कॉन्फ़िगर नहीं बदला गया था, न ही कोई PHP स्क्रिप्ट थी। यह डिस्क स्थान से बाहर नहीं है। मेरा आवेदन सिर्फ PHPस्क्रिप्ट का एक सेट है । मैं उपयोग नहीं कर php-fpmरहा हूँ, मैं बस php-fastcgiकर रहा हूँ php-cgi -b 127.0.0.1:9000। यह 3 साल से बिना गलती के काम कर रहा है। मैं इस मुद्दे को विकसित क्यों नहीं कर सकता।

— निगेल एल्डर्टन

मेरे पास हाल ही में इसी तरह का मुद्दा था, जहां नग्नेक्स ने अपस्ट्रीम से प्रतिक्रिया हेडर पढ़ते हुए सहकर्मी द्वारा कनेक्शन रीसेट के बारे में शिकायत की थी, मेरे मामले में यह uWSGI था जो वास्तविक समस्या थी, फिर से शुरू करना uWSGI ने मेरे लिए समस्या को निर्धारित किया, जैसे कि ऐसा क्यों हो रहा है यह एक अलग है। मुद्दा।

— APZ

आपकी अपस्ट्रीम सेवा ( php-cgi -b 127.0.0.1:9000) आंतरायिक रूप से विफल हो रही है, शायद बढ़ते यातायात और संसाधनों की कमी के कारण।

— LinuxDevOps

Answer 1

मुझे हमेशा भरोसा रहेगा अगर मेरे वेबसर्वर मुझे बता रहे हैं: 502 Bad Gateway

• आपके fastcgi / nginx - प्रक्रिया का क्या समय है?
• क्या आप नेटवर्क-कनेक्शन की निगरानी करते हैं?
• क्या आप उस दिन के आसपास आने-जाने वालों की संख्या में बदलाव की पुष्टि / खंडन कर सकते हैं?

इसका क्या मतलब है:

• आप फास्टगि-प्रक्रिया नंगेक्स द्वारा सुलभ नहीं हैं; या तो धीमा या बिल्कुल भी नहीं। खराब गेटवे का मतलब है: नगनेक्स उस परिभाषित ressource 127.0.0.1:9000 को fastcgi_pass नहीं कर सकता है; उस बहुत विशिष्ट क्षण में ।

• आपकी जन्मजात त्रुटि-लॉग यह सब बताता है:

।

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

मेरे सीमित पीओवी से मैं सुझाव दूंगा:

• अपना fastcgi_process / server पुनः आरंभ करें
• अपने प्रवेश-लॉग की जाँच करें
• डीबग-लॉग सक्षम करें

Comments

ठीक। मेरे वेबसेवर मुझे क्या बता रहे हैं?

— निगेल एल्डर्टन

मेरा संपादन देखें (इसका क्या मतलब है)

— वह आदमी वहाँ से

मैं देख रहा हूं, इसलिए Gatewayइस मामले में PHP सर्वर है। धन्यवाद।

— निगेल एल्डर्टन

restart your fastcgi_process / serverक्या मेरी मदद की,

— धन्यवाद

Answer 2

मुझे पता है कि यह विषय पुराना है, लेकिन यह अभी भी कभी-कभी पॉप अप करना जारी रखता है, इसलिए, वेब पर उत्तरों की तलाश में, मैं निम्नलिखित तीन संभावनाओं के साथ आया हूं:

1. एक प्रोग्रामिंग त्रुटि कभी-कभी php-fpm segfaulting होती है, जिसका अर्थ है कि नगनेक्स के साथ संबंध विच्छेद हो जाएगा। यह आमतौर पर कम से कम कुछ लॉग के आसपास और / या कोर डंप को छोड़ देगा, जिसका आगे विश्लेषण किया जा सकता है।
2. किसी कारण से, PHP सत्र फ़ाइल (आमतौर पर:) लिखने में सक्षम नहीं हो रही है session.save_path = "/var/lib/php/sessions"। यह खराब अनुमतियाँ, खराब स्वामित्व, खराब उपयोगकर्ता / समूह, या अधिक गूढ़ / अस्पष्ट मुद्दे हो सकते हैं जैसे कि उस निर्देशिका पर इनोड से बाहर (या एक पूर्ण डिस्क!)। यह आमतौर पर आसपास कई कोर डंप नहीं छोड़ता है और संभवतः PHP त्रुटि लॉग पर भी कुछ भी नहीं।
3. डीबग करने के लिए और भी अधिक मुश्किल: एक एक्सटेंशन दुर्व्यवहार कर रहा है (कभी-कभी किसी प्रकार की आंतरिक सीमा, या एक बग जो हर समय ट्रिगर नहीं होता है), सीगफॉल्टिंग, और php-fpm प्रक्रिया को नीचे लाने के साथ - इस प्रकार nginx के साथ संबंध बंद करना। । सामान्य अपराधी APC, मेम्चेचे / d, आदि हैं (मेरे मामले में यह नया अवशेष एक्सटेंशन था), इसलिए यहां पर विचार प्रत्येक एक्सटेंशन को तब तक बंद करना है जब तक कि त्रुटि गायब न हो जाए।

Comments

+1 मेरे मामले में यह # 1 - प्रोग्रामिंग त्रुटि थी।

— निंबुज

हम इस त्रुटि में भाग गए और नई Relic APM PHP एक्सटेंशन को अक्षम करने से एक और अधिक विशिष्ट त्रुटि का पता चला, जिसने हमें समस्या को ट्रैक करने की अनुमति दी: [29-Jan-2018 16:47:48 UTC] PHP घातक त्रुटि: 805309368 बाइट्स की अनुमत स्मृति आकार थका हुआ (262144 बाइट्स आवंटित करने का प्रयास) विक्रेता / magento / मॉड्यूल-कॉन्फ़िगर करने योग्य-उत्पाद / मूल्य निर्धारण / मूल्य / कॉन्फ़िगर करने योग्यRegularPrice.php पर लाइन 142 [29-Jan-2018 16:47:48 UTC] PHP घातक त्रुटि: स्वीकृत मेमोरी आकार 805306368 बाइट्स थका हुआ (323584 बाइट्स आवंटित करने की कोशिश की) अज्ञात में लाइन 0 पर मेरा अनुमान है कि न्यू रेलिक ने "अनजान" पथ पर घुटा हुआ है।

— एरिक हैनसेन

Answer 3

यह भी हो रही है। opcacheयदि आपने इसका उपयोग किया है (APC के लिए प्रतिस्थापन), मेमोरी सीमा बढ़ाकर इसे हल किया । जब भी कैश बहुत अधिक भरा हो, तो PHP-FPM ने कनेक्शन छोड़ दिया। यही कारण है कि shgnInc का उत्तर इसे थोड़े समय के लिए ठीक करता है।

तो फ़ाइल को खोजें /etc/php5/fpm/php.ini(या आपके वितरण में समतुल्य) और memory_consumptionआपकी साइट को जो भी स्तर की आवश्यकता हो उसे बढ़ाएं । अक्षम करने से opcacheभी काम चल सकता है।

[opcache]
opcache.memory_consumption = 196 

Answer 4

आप इस gitub पर gitub पर विचार करना चाह सकते हैं: https://gist.github.com/amichaelgrant/90d99d7d5d48bf8fd209

मुझे इसी तरह की स्थिति का सामना करना पड़ा, जब मैंने अपने अपस्ट्रीम सर्वर के लिए त्रुटि लॉग की जांच की तो वे कुछ अलिमित त्रुटि की सूचना दे रहे थे, इसलिए मैंने इसे बढ़ाकर 1000000 (दोनों अपस्ट्रीम और नेग्नेक्स बॉक्स पर) और सब कुछ ठीक काम किया

Answer 5

मेरी इसी समस्या के मामले में, मैं अभी php-fpmसेवा को पुनः आरंभ करता हूं ताकि यह हल हो जाए।

sudo service php5-fpm restart

या कुछ बार अनुरोधों के विशाल होने के कारण यह समस्या होती है। डिफ़ॉल्ट रूप से pm.max_requestsphp5-fpm में शायद 100 या नीचे है।

इसे हल करने के लिए इसका मूल्य आपकी साइट के अनुरोधों पर निर्भर करता है, उदाहरण के लिए 500।

और इसके बाद आपको सर्विस को रिस्टार्ट करना होगा

Answer 6

मेरे मामले में, xdebug एक्सटेंशन को अक्षम करने से मदद मिली।

Comments

ditto, मेरे मामले में मैंने एक ब्रेकपॉइंट के लिए एक शर्त निर्धारित की और उस क्षण में मैंने ब्रेकपॉइंट को अक्षम कर दिया कि त्रुटि हो गई थी।

— roman204

Answer 7

मुझे बस एक ही समस्या थी:

आप पोर्ट 9000 पर php-fpm से कनेक्ट करें। (Fastcgi: //127.0.0.1: 9000)

मेरे सर्वर पर उबंटू पर मानक विन्यास है:

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

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

आपको इसे इसमें बदलना होगा:

listen = 0.0.0.0:9000

मेरे मामले में, मैंने डिफ़ॉल्ट के साथ अपने कॉस्टोम कॉन्फ़िगरेशन को ओवरराइट करते हुए 1 1/2 महीने पहले अपने सर्वर को अपडेट किया था। अब php-fpm को पुनः आरंभ करने से यह त्रुटि देरी से लागू हुई।

Answer 8

मेरे लिए यह OOM किलर द्वारा मारे जा रहे मेमोरी और php-fpm से बाहर निकलने वाला सर्वर था। इसका समाधान सर्वर मेमोरी की मात्रा बढ़ाना था।

Answer 9

मेरे लिए यह इसलिए था क्योंकि php-fpm max_childrenसीमा को मार रहा था । प्रश्न में पूल के लिए php-fpm लॉग ने मुझे सही दिशा में इंगित किया

Answer 10

यह समस्या तब भी उत्पन्न हो सकती है यदि कोई PHP-FPM प्रक्रिया अपनी आवंटित स्मृति सीमा से अधिक हो। जब ऐसा होता है, तो NGINX और PHP-FPM के बीच संबंध विच्छेद हो जाता है और NGINX रिटर्न देता है 502 Bad Gateway। PHP-FPM प्रक्रिया मेमोरी लिमिट को memory_limitवेरिएबल द्वारा नियंत्रित किया जाता है। इसे php_admin_value[memory_limit]PHP-FPM कॉन्फ़िगरेशन फ़ाइल के साथ सेट किया जा सकता है ।

यह ध्यान रखना महत्वपूर्ण है कि स्मृति सीमा प्रति-स्क्रिप्ट के आधार पर लागू होती है । साथ nपीएचपी-एफ पी एम प्रक्रियाओं, कुल स्मृति के उपयोग तक हो सकती है memory_limit * n। यह जांचना सुनिश्चित करें कि आपकी मशीन में पर्याप्त मेमोरी हेडरूम है!