Nginx 502 503 오류 트리거 조건 및 해결 방법 집합

Nginx 에서 운영 되 는 일부 사이트 에 서 는 때때로 '502 Bad Gateway' 오류 가 발생 하고, 때로는 빈번하게 발생 하기 도 한다.일부 역장 들 은 Nginx 로 옮 긴 직후 부터 이 문제 가 발생 해 Nginx 문제 가 아니 냐 는 의심 을 자주 받 지만 사실은 잘못된 부분 이다.
 
Nginx 502 오 류 는 프 록 시 모드 에서 백 엔 드 서버 에 문제 가 생 겨 발생 한 원인 이 많 습 니 다.이러한 오 류 는 일반적으로 nginx 자체 의 문제 가 아니 므 로 반드시 백 엔 드 에서 원인 을 찾 아야 합 니 다!그러나 nginx 는 이러한 실 수 를 모두 자신 에 게 맡 겼 고 nginx 의 홍보 자 들 로 하여 금 의심 을 받 게 했다. 왜냐하면 단어 적 으로 'bad gateway' 를 이해 하기 때문이다.바로 badnginx 아닌가 요?모 르 는 사람 에 게 보 여주 면 직접 nginx 에 게 책임 을 떠 넘 기 고 nginx 다음 버 전 은 오류 알림 을 약간 우호 적 으로 쓰 기 를 바 랍 니 다. 적어도 현재 의 간단 한 문장 인 502 Bad Gateway 는 아 닙 니 다. 그리고 자신의 이름 을 붙 이 는 것 도 잊 지 않 습 니 다.
Nginx 502 의 트리거 조건
502 오류 의 가장 일반적인 상황 은 백 엔 드 호스트 가 컴퓨터 에 있 는 것 이다.upstream 설정 에 다음 설정 이 있 습 니 다: proxynext_upstream, 이 설정 은 nginx 가 백 엔 드 호스트 에서 데 이 터 를 가 져 오 는 데 어떤 오류 가 발생 했 을 때 다음 백 엔 드 호스트 로 이동 하 는 지 지정 합 니 다. 안에 적 힌 것 은 502 의 모든 상황 이 발생 하 는 것 입 니 다. 기본 값 은 error timeout 입 니 다.error 는 바로 컴퓨터, 단선 같은 것 입 니 다. timeout 은 읽 기 막 히 고 시간 이 초과 되 어 이해 하기 쉽 습 니 다.나 는 보통 모두 쓴다.
 

proxy_next_upstream error timeout invalid_header http_500 http_503;

 
하지만 지금 은 http 를 없 애 야 할 것 같 습 니 다.500 이 항목 입 니 다. http500 지정 한 백 엔 드 가 500 오 류 를 되 돌 릴 때 호스트 를 돌 립 니 다. 백 엔 드 jsp 가 잘못 되면 stacktrace 의 오류 정 보 를 인쇄 할 수 있 었 는데 502 로 대체 되 었 습 니 다.그러나 회사 의 프로그래머 들 은 그렇게 생각 하지 않 습 니 다. 그들 은 nginx 에 오류 가 생 겼 다 고 생각 합 니 다. 저 는 그들 에 게 502 의 원 리 를 설명 할 시간 이 없습니다.
503 오 류 는 보류 할 수 있 습 니 다. 백 엔 드 는 보통 apache resin 이기 때문에 apache 가 다운 되면 error 이지 만 resin 이 다운 되 고 503 에 불과 하기 때문에 보류 할 필요 가 있 습 니 다.
해결 방법
502 문제 에 부 딪 히 면 다음 과 같은 두 단계 로 해결 하 는 것 을 우선적으로 고려 할 수 있다.
1. 현재 PHP FastCGI 프로 세 스 수가 충분 한 지 확인 하기:
 

netstat -anpo | grep "php-cgi" | wc -l

 
실제 사 용 된 'FastCGI 프로 세 스 수' 가 미리 설 정 된 'FastCGI 프로 세 스 수' 에 가깝다 면 'FastCGI 프로 세 스 수' 가 부족 하고 커 져 야 한 다 는 뜻 이다.
2. 일부 PHP 프로그램의 실행 시간 이 Nginx 의 대기 시간 을 초과 하여 nginx. conf 설정 파일 에서 FastCGI 의 timeout 시간 을 적당 하 게 증가 시 킬 수 있 습 니 다. 예 를 들 어:
 

......
http
{
......
fastcgi_connect_timeout 300;
fastcgi_send_timeout 300;
fastcgi_read_timeout 300;
......
}
......

 
php. ini 중 memorylimit 설정 을 낮 추 면 오류 가 발생 합 니 다. php. ini 의 memory 를 수 정 했 습 니 다.limit 은 64M 입 니 다. nginx 를 다시 시작 합 니 다. PHP 메모리 가 부족 한 것 을 발 견 했 습 니 다.
만약 이렇게 수정 해도 문 제 를 해결 할 수 없다 면 다음 과 같은 방안 을 참고 할 수 있다.
1. max - children 과 max - requests
서버 에서 nginx phop (fpm) xcache 가 실행 되 고 있 으 며, 방 문 량 은 하루 평균 300 W pv 정도 입 니 다.
최근 에는 phop 페이지 가 늦게 열 리 고 cpu 사용률 이 갑자기 낮 아 지면 서 시스템 부하 가 갑자기 높 아 졌 다. 네트워크 카드 의 트 래 픽 을 보면 갑자기 낮 아 졌 다 는 것 을 알 수 있다.이런 상황 은 몇 초 만 에 회복 되 었 다.
php - fpm 로그 파일 검사 에서 단 서 를 발 견 했 습 니 다.
 

Sep 30 08:32:23.289973 [NOTICE] fpm_unix_init_main(), line 271: getrlimit(nofile): max:51200, cur:51200
Sep 30 08:32:23.290212 [NOTICE] fpm_sockets_init_main(), line 371: using inherited socket fd=10, “127.0.0.1:9000″
Sep 30 08:32:23.290342 [NOTICE] fpm_event_init_main(), line 109: libevent: using epoll
Sep 30 08:32:23.296426 [NOTICE] fpm_init(), line 47: fpm is running, pid 30587

 
이 몇 마디 앞 에는 1000 여 줄 의 children 닫 기와 children 로그 열기 가 있 습 니 다.
원래 php - fpm 에 인자 max 가 있 었 습 니 다.requests, 이 매개 변 수 는 children 당 최대 몇 개의 요청 을 처리 하면 닫 히 고 기본 설정 은 500 입 니 다.php 는 요청 을 모든 children 에 게 돌아 가면 서 대량의 데이터 에서 childre 마다 max 에 도달 하기 때 문 입 니 다.requests 가 사용 하 는 시간 이 많 지 않 아서 모든 children 이 기본적으로 같은 시간 에 닫 힙 니 다.
이 기간 에 nginx 는 phop 파일 을 phop - fpm 에 전달 할 수 없 기 때문에 cpu 는 매우 낮 아 집 니 다 (phop 을 처리 하지 않 고 sql 을 실행 하지 않 아 도 됩 니 다). 부하 가 높 아 집 니 다 (children 을 닫 고 켜 고 nginx 는 phop - fpm 를 기다 리 고 있 습 니 다). 네트워크 카드 트 래 픽 도 낮 아 집 니 다 (nginx 는 데이터 전송 을 클 라 이언 트 에 생 성 할 수 없습니다).
문 제 를 해결 하 는 것 은 간단 합 니 다. children 의 수 를 늘 리 고 maxrequests 설정 이 0 이 되 지 않 았 거나 큰 값:
/ usr / local / php / etc / php - fpm. conf 열기
다음 두 개의 인 자 를 확대 합 니 다 (서버 의 실제 상황 에 따라 너무 커 도 안 됩 니 다)
 

<value name=”max_children”>5120</value>
<value name=”max_requests”>600</value>

 
그리고 php - fpm 를 다시 시작 합 니 다.
2. 버퍼 용량 크기 증가
nginx 의 error log 를 열 면 'pstream sent too big header while reading response header from upstream' 이라는 오류 알림 을 발견 할 수 있 습 니 다.자 료 를 찾 아 보 았 는데 대 의 는 nginx 버퍼 에 bug 가 있어 서 우리 사이트 의 페이지 소모 가 버퍼 를 너무 많이 차지 할 수 있 습 니 다.외국인 이 쓴 수정 방법 을 참고 하여 버퍼 용량 크기 설정 을 추 가 했 고 502 문 제 를 철저히 해결 했다.그 후에 시스템 관리 자 는 매개 변 수 를 조정 하여 두 개의 설정 매개 변수 만 남 겼 습 니 다. client head buffer, fastcgi buffer size.
3. requestterminate_timeout
정적 페이지 작업 에서 흔히 볼 수 있 는 것 이 아니 라 post 나 데이터 베 이 스 를 조작 할 때 502 상황 이 발생 한다 면 pp - fpm. conf 설정 중 하 나 를 볼 수 있 습 니 다.
　　request_terminate_timeout
이 값 은 maxexecution_time, fast - cgi 의 스 크 립 트 실행 시간 입 니 다.
　　0s
0 s 가 닫 히 기 위해 서 는 무한 실행 입 니 다.(패션 할 때 자세히 보지 않 고 숫자 를 바 꿨 다)
문제 가 해결 되 었 으 니 오랫동안 집행 해도 틀 리 지 않 을 것 이다.
fastcgi 를 최적화 하면 이 값 5s 를 고 쳐 서 효 과 를 볼 수 있 습 니 다.
php - cgi 프로 세 스 수가 부족 하거나 php 가 오래 실행 되 거나 php - cgi 프로 세 스 가 죽 으 면 502 오류 가 발생 합 니 다.
만약 당신 에 게 또 다른 해결 방법 이 있다 면, 편집 과 소통 하 는 것 을 환영 합 니 다!물론, 만약 당신 의 사이트 의 병발 량 이 확실히 크다 면, 최종 적 으로 시스템 급 의 해결 방법 을 찾 아야 할 지도 모른다.