Nginx 502 및 Nginx 504용 솔루션

이 두 가지 문제를 해결하려면 실제로 포괄적인 사고가 필요합니다.일반적으로 Nginx 502 Bad Gateway는 php-fpm.conf 설정과 관련이 있고 Nginx 504 Gateway Time-out은 nginx.conf 설정과 관련됩니다.

  올바른 설정은 서버 자체의 성능 및 방문자 수와 같은 여러 요소를 고려해야 합니다.

  fastcgi_connect_timeout 300초;

  fastcgi_send_timeout 300초;

  fastcgi_read_timeout 300초;

  fastcgi_buffer_size 128k;

  fastcgi_buffers 8 128k;#8 128

  fastcgi_busy_buffers_size 256k;

  fastcgi_temp_file_write_size 256k;

  fastcgi_intercept_errors 켜짐;

  여기서 가장 중요한 설정은 처음 세 가지입니다.

  fastcgi_connect_timeout 300초;

  fastcgi_send_timeout 300초;

  fastcgi_read_timeout 300초;

  여기에는 PHP-CGI의 연결, 전송 및 읽기 시간이 규정되어 있으며 300초면 충분하므로 내 서버에서 504 Gateway Time-out 오류가 거의 발생하지 않습니다. 가장 중요한 것은 502 Bad Gateway 및 504 Gateway Time-out으로 직접 연결되는 php-fpm.conf의 설정입니다.

  php-fpm.conf의 몇 가지 중요한 매개변수를 자세히 살펴보겠습니다.

  php-fpm.conf에는 두 가지 중요한 매개변수가 있습니다. 하나는 "max_children"이고 다른 하나는 "request_terminate_timeout"입니다.

  내 두 설정 중 하나는 "40"이고 다른 하나는 "900"이지만 이 값은 보편적이지 않고 직접 계산해야 합니다.

  계산 방법은 다음과 같습니다.

  서버 성능이 충분하고 광대역 리소스가 충분하며 PHP 스크립트에 루프나 버그가 없는 경우 "request_terminate_timeout"을 0으로 직접 설정할 수 있습니다. 0의 의미는 PHP-CGI가 시간 제한 없이 계속 실행되도록 하는 것입니다. 이렇게 할 수 없는 경우 즉, PHP-CGI에 버그가 있거나 광대역이 충분하지 않거나 다른 이유로 PHP-CGI가 멈출 수 있는 경우 다음을 수행하는 것이 좋습니다. "request_terminate_timeout" 값을 할당합니다. 이 값은 서버 성능에 따라 설정할 수 있습니다. 일반적으로 성능이 좋을수록 높게 설정할 수 있으며 20분에서 30분이 적당합니다. 내 서버 PHP 스크립트는 장시간 실행해야 하므로 일부는 10분을 초과할 수 있으므로 PHP-CGI가 죽지 않고 오류 502 Bad gateway가 나타나지 않도록 900초로 설정했습니다.

  그리고 "max_children" 값은 어떻게 계산되나요? 원칙적으로 값이 클수록 좋습니다. php-cgi 프로세스가 많을수록 빠르게 처리되고 대기 중인 요청이 줄어듭니다. "max_children" 설정도 서버의 성능에 따라 설정이 필요합니다. 일반적으로 정상적인 상황에서 서버의 각 php-cgi가 소비하는 메모리는 약 20M이므로 "max_children"은 40, 20M으로 설정합니다. * 40=800M은 피크 시간에 모든 PHP-CGI가 소비하는 메모리가 800M 이내라는 것을 의미하며, 이는 내 유효 메모리인 1Gb보다 낮습니다. 그리고 내 "max_children" 설정이 5-10과 같이 작으면 php-cgi가 "매우 피곤"하고 처리 속도가 매우 느려지고 대기 시간이 길어집니다. 요청이 오랫동안 처리되지 않으면 오류 504 Gateway Time-out이 표시되고 처리 중인 몇 개의 php-cgi가 지치면 문제가 발생하면 오류 502 Bad gateway가 표시됩니다.

동시에 nginx 버퍼 크기 /www/server/nginx/conf/proxy.conf를 설정할 수 있습니다.

통용 배치

proxy_buffer_size 4k; # 사용자 헤더 정보를 저장하기 위한 프록시 서버(nginx)의 버퍼 크기를 설정합니다.
proxy_buffers 4 32k; #proxy_buffers 버퍼, 평균 웹 페이지를 32k 이하로 설정합니다.
proxy_busy_buffers_size 64k; #고부하 시 버퍼 크기(proxy_buffers*2)
proxy_temp_file_write_size 64k ;#캐시 폴더의 크기를 설정합니다. 이 값보다 크면 업스트림 서버에서 업로드됩니다.

具體配置如下 
proxy_buffering on;
프록시_버퍼_크기 100M;
프록시_버퍼 8 100M;
proxy_busy_buffers_size 100M;
proxy_max_temp_file_size 0;

--------------------------------------------------

Nginx 502 Bad Gateway의 의미는 요청한 PHP-CGI가 실행되었지만 어떤 이유로(일반적으로 리소스 읽기 문제) PHP-CGI 프로세스가 실행되지 않고 PHP-CGI 프로세스가 종료된다는 것입니다. , Nginx 502 Bad Gateway 및 php- fpm.conf 설정이 관련되어 있습니다.

일반적인 이유는 php-cgi 프로세스의 수가 충분하지 않거나 php의 실행 시간이 길거나(mysql이 느림) php-cgi 프로세스가 종료되어 502 오류가 나타나는 것일 수 있습니다.

1. 설치된 환경에서 일정 시간 실행 후 502 문제가 발생합니다.일반적으로 기본 php-cgi 프로세스가 5번이기 때문입니다.phpcgi 프로세스가 부족하여 502가 발생할 수 있습니다./ usr/local/php/etc/php -fpm.conf는 max_children의 값을 적절하게 증가시킵니다.

2. PHP 실행 시간 초과, /usr/local/php/etc/php.ini를 수정하여 max_execution_time을 300으로 변경

3. 디스크 공간이 부족하면 # df -h 명령을 사용하여 디스크 사용량을 확인할 수 있습니다.

4. php-cgi 프로세스가 종료되었습니다.

일반적인 문제 해결 방법은 다음과 같습니다.

1. php fastcgi의 프로세스 수 보기(max_children 값)

# netstat -anop | grep php-cgi | wc -l
# netstat -anpo | grep php-fpm | 화장실 -l

디스플레이가 5인 경우

2. 현재 프로세스 보기
# ps aux | grep php-fpm fastcgi/php-fpm 프로세스 수를 관찰하여 사용하는 프로세스 수가 5개 이상이면 늘려야 함을 의미합니다.

3. /usr/local/php/etc/php-fpm.conf의 관련 설정을 조정합니다.

pm.max_children = 5
request_terminate_timeout = 60

max_children은 최대 5개의 프로세스를 가지며 각 프로세스는 20MB, 최대 100MB의 메모리를 갖습니다. 즉 1분입니다. max_children이 증가하면 더 많은 php-cgi 프로세스가 빠르게 처리되고 대기 중인 요청이 줄어듭니다. 그러나 max_children 설정도 서버의 성능에 따라 설정해야 하며 일반적으로 정상적인 상황에서 서버의 각 php-cgi가 소비하는 메모리는 약 20M입니다. 실제 결정은 자체 서버에서 구입한 메모리를 기반으로 합니다.
request_terminate_timeout의 실행 시간은 60초이며, request_terminate_timeout의 값은 서버의 성능에 따라 설정할 수 있습니다. 일반적으로 성능이 좋을수록 높게 설정할 수 있으며 20분에서 30분이 적당합니다.

4. 일부 PHP 프로그램의 실행 시간이 Nginx의 대기 시간을 초과합니다. nginx.conf 구성 파일에서 FastCGI의 시간 초과 시간을 적절하게 늘릴 수 있습니다. 예를 들면 다음과 같습니다.

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





Guess you like

Origin blog.csdn.net/tiging/article/details/130347738