nginx 오류“업스트림에서 응답 헤더를 읽는 동안 recv () 실패 (104 : 피어에 의한 연결 재설정)”


44

클라이언트에 "502 Bad Gateway"오류가 간헐적으로 반환되기 시작한 2013 년 10 월 3 일 오전 10시 50 분까지 정상적으로 작동하는 서버가 있습니다.

브라우저 요청 5 개 중 약 4 개는 성공하지만 502 개 중 약 5 개 중 1 개는 실패합니다.

nginx 오류 로그에는 수백 가지 오류가 포함되어 있습니다.

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

그날 무엇이 바뀌 었습니까? 응용 프로그램 또는 PHP를 업데이트 했습니까? 당신의 신청은 무엇입니까? php-fpm에서 디버깅을 활성화 했습니까?
Pothi Kalimuthu

그날 아무것도 바뀌지 않았습니다. 서버 설정은 변경되지 않았으며 PHP 스크립트도 변경되지 않았습니다. 디스크 공간이 부족하지 않습니다. 내 응용 프로그램은 일련의 PHP스크립트입니다. 나는을 사용하지 않고 php-fpm, 그냥 실행 php-fastcgi하여 실행 중 php-cgi -b 127.0.0.1:9000입니다. 3 년 동안 완벽하게 작동 해 왔습니다. 왜이 문제가 발생했는지 알 수 없습니다.
Nigel Alderton

나는 최근에 nginx가 업스트림에서 응답 헤더를 읽는 동안 피어에 의한 연결 재설정에 대해 불평하는 비슷한 문제를 겪었습니다. 제 경우에는 실제 문제 인 uWSGI였습니다 .uWSGI를 다시 시작하면 문제가 발생하는 이유는 별도입니다. 발행물.
APZ

php-cgi -b 127.0.0.1:9000트래픽 증가와 리소스 부족으로 인해 업스트림 서비스 ( )가 간헐적으로 실패하고 있습니다.
LinuxDevOps

답변:


22

내 웹 서버가 나에게 말하면 항상 신뢰합니다. 502 Bad Gateway

  • fastcgi / nginx-프로세스의 가동 시간은 무엇입니까?
  • 네트워크 연결을 모니터링합니까?
  • 그날 방문자 수 변경을 확인 / 거부 할 수 있습니까?

무슨 뜻인가요:

  • nginx는 fastcgi-process에 액세스 할 수 없습니다. 느리게하거나 전혀 해당하지 않습니다. 불량 게이트웨이는 nginx가 정의 된 자원 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???

제한된 POV에서 다음과 같이 제안합니다.

  • fastcgi_process / 서버를 다시 시작하십시오
  • 액세스 로그를 확인하십시오
  • 디버그 로그 활성화

승인. 내 웹 서버가 알려주는 것은 무엇입니까?
Nigel Alderton 2014 년

(이 말은 무엇을) 내 편집을 참조
저기에서 그 사람

2
알다시피, Gateway이 경우에는 PHP 서버입니다. 감사합니다.
Nigel Alderton

restart your fastcgi_process / server나를 도와주었습니다.
realtebo

11

나는이 주제가 오래되었다는 것을 알고 있지만 여전히 계속 팝업되어 웹에서 답을 찾고 다음 세 가지 가능성을 생각해 냈습니다.

  1. 프로그래밍 오류로 인해 php-fpm이 segfaulting되어 nginx와의 연결이 끊어 질 수 있습니다. 이것은 일반적으로 적어도 일부 로그 및 / 또는 코어 덤프를 남겨두고, 더 분석 할 수 있습니다.
  2. 어떤 이유로 PHP는 세션 파일을 작성할 수 없습니다 (보통 :) session.save_path = "/var/lib/php/sessions". 이는 잘못된 권한, 나쁜 소유권, 나쁜 사용자 / 그룹 또는 해당 디렉토리의 inode 부족 (또는 전체 디스크)과 같은 난해한 / 불분명 한 문제 일 수 있습니다. 이것은 보통됩니다 하지 많은 코어는 아마도 PHP 오류 로그에조차 아무것도 주위 덤프와 둡니다.
  3. 디버깅하기가 더 까다로워집니다. 확장 기능이 잘못 작동하거나 (종종 내부 제한에 부딪 히거나 버그가 항상 발생하지 않는 버그), segfaulting 및 php-fpm 프로세스 중단으로 인해 nginx와의 연결이 끊어짐 . 일반적인 범인은 APC, memcache / d 등입니다 (제 경우에는 New Relic 확장명). 따라서 오류가 사라질 때까지 각 확장을 끄는 것이 좋습니다.

+1 제 경우에는 # 1-프로그래밍 오류였습니다.
님 부즈

이 오류가 발생하여 New Relic APM PHP 확장을 비활성화하면 문제를 추적 할 수있는보다 구체적인 오류가 드러났습니다. [29-Jan-2018 16:47:48 UTC] PHP 치명적인 오류 : 허용되는 메모리 크기 805306368 바이트 142 번째 줄의 vendor / magento / module-configurable-product / Pricing / Price / ConfigurableRegularPrice.php에서 소진되었습니다 (262144 바이트를 할당하려고 시도 함). [29-Jan-2018 16:47:48 UTC] PHP 치명적인 오류 : 허용 된 메모리 크기 805306368 0 행의 Unknown에서 소진 된 (323584 바이트를 할당하려고 시도한) 바이트입니다. New Relic이 "알 수없는"경로에서 질식 한 것 같습니다.
Erik Hansen

7

이것을 얻는 것도 계속했다. opcache사용하는 경우 메모리 한계 를 늘려서 해결하십시오 (APC 대체). 캐시가 가득 찰 때마다 PHP-FPM이 연결을 끊은 것 같습니다. 이것은 shgnInc의 답변이 짧은 시간 동안 문제를 해결하는 이유이기도합니다.

따라서 파일 /etc/php5/fpm/php.ini(또는 배포판에서 동등한 파일)을 찾아 memory_consumption사이트에 필요한 수준으로 늘리 십시오. 비활성화 opcache해도 작동 할 수 있습니다.

[opcache]
opcache.memory_consumption = 196 

2

github 에서이 자식을 고려할 수 있습니다 : https://gist.github.com/amichaelgrant/90d99d7d5d48bf8fd209

비슷한 상황이 발생했습니다. 업스트림 서버에 대한 오류 로그를 확인할 때 일부 ulimit 오류를보고했기 때문에 업스트림 및 nginx 상자 모두에서 1000000으로 늘리고 모든 것이 잘 작동했습니다.


2

같은 문제가 발생하면 php-fpm서비스를 다시 시작하여 해결했습니다.

sudo service php5-fpm restart

또는 때때로이 문제는 많은 요청으로 인해 발생합니다. 기본적 pm.max_requests으로 php5-fpm의 값은 100 이하입니다.

이 문제를 해결하려면 사이트 요청에 따라 값을 늘리십시오 (예 : 500).

그리고 당신은 서비스를 다시 시작해야


2

제 경우에는 xdebug 확장 기능을 비활성화 하면 도움이되었습니다.


ditto, 내 경우에는 중단 점에 대한 조건을 설정하고 그 순간 breackpoint를 비활성화하고 오류가 사라졌습니다.
roman204

1

방금 비슷한 문제가있었습니다.

포트 9000에서 php-fpm에 연결합니다 (fastcgi : //127.0.0.1 : 9000).

내 서버의 Ubuntu에서 표준 구성은 다음과 같습니다.

/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 개월 전에 서버를 업데이트하여 costom 구성을 기본값으로 덮어 썼습니다. 이제 php-fpm을 다시 시작하면이 오류가 지연되었습니다.


1

나에게 그것은 메모리가 부족하고 OOM-killer에 의해 php-fpm이 죽는 서버였습니다. 해결책은 서버 메모리 양을 늘리는 것이 었습니다.


1

나에게는 php-fpm이 max_children한계 에 도달했기 때문 입니다. 문제의 풀에 대한 php-fpm 로그가 올바른 방향으로 나를 가리 켰습니다.


0

PHP-FPM 프로세스가 할당 된 메모리 제한을 초과하는 경우에도이 문제가 발생할 수 있습니다. 이 경우 NGINX와 PHP-FPM 간의 연결이 끊어지고 NGINX는을 반환합니다 502 Bad Gateway. PHP-FPM 프로세스 메모리 한계는 memory_limit변수에 의해 제어됩니다 . 이것은 php_admin_value[memory_limit]PHP-FPM 구성 파일에서 설정할 수 있습니다 .

메모리 제한 은 스크립트 단위로 적용됩니다 . 와 nPHP-FPM 프로세스, 총 메모리 사용량이 최대 일 수있다 memory_limit * n. 머신에 충분한 메모리 헤드 룸이 있는지 확인하십시오!

당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.