1분 만에 PHP-FPM 구성 및 사용 요약 이해

우리는 PHP에 대해 많은 것을 배웠습니다. PHP-FPM 구성 및 사용법 요약을 완전히 마스터했는지 궁금합니다. 그렇지 않다면 이 기사를 따라 계속 학습하세요.

PHP-FPM 구성 및 사용법 요약:

PHP-FPM은 실제로 PHP 소스 코드의 패치입니다. 이는 PHP 소프트웨어 패키지에 FastCGI 프로세스 관리를 도입하기 위해 설계되었으며, 이를 PHP 소스 코드에 패치해야 합니다. 그것은 사용될 수 있습니다. 이제 PHP 5.3.2 및 최신 버전에서 직접 열고 사용할 수 있습니다. 왜냐하면 PHP가 이 버전의 소프트웨어 패키지에 포함했기 때문에 더 이상 패치 패키지로 존재하지 않기 때문입니다.

· 여러 개념의 이해

· Nginx+PHP 구성

· Php-Fpm 작동

1. 여러 개념의 이해

1), CGI

CGI는 "Common Gateway Interface" 인터페이스를 의미합니다. HTTP 서버가 다른 컴퓨터의 프로그램과 통신하는 인터페이스이며 해당 프로그램은 네트워크 서버에서 실행되어야 합니다.

참고:

CGI는 언어에 표준 입력, 출력 및 환경 변수가 있는 한 어떤 언어로든 작성할 수 있습니다.

2), FastCGI

FastCGI는 항상 실행될 수 있습니다. 활성화되어 있는 한 매번 포크하는 데 시간이 걸리지 않습니다. CGI). 또한 분산 컴퓨팅을 지원합니다. 즉, FastCGI 프로그램은 웹 사이트 서버가 아닌 호스트에서 실행될 수 있으며 다른 웹 사이트 서버의 요청을 수락할 수 있습니다.

FastCGI는 언어 독립적이고 확장 가능한 아키텍처 CGI 개방형 확장입니다. 주요 동작은 CGI 인터프리터 프로세스를 메모리에 유지하여 더 높은 성능을 얻는 것입니다. CGI 인터프리터의 반복적인 로딩이 CGI 성능 저하의 주요 원인이라는 것을 알고 있습니다. CGI 인터프리터가 메모리에 저장되고 FastCGI 프로세스 관리자에 의해 승인되면 우수한 성능, 확장성 등을 제공할 수 있습니다.

장점:

1. FastCGI는 언어 독립적입니다.

2. FastCGI는 핵심 웹 서버와 독립적으로 실행되어 API보다 더 안전한 환경을 제공합니다. API는 애플리케이션의 코드를 핵심 웹 서버와 연결합니다. 즉, 잘못된 API를 사용하는 애플리케이션은 다른 애플리케이션이나 핵심 서버를 손상시킬 수 있습니다. 악성 API 애플리케이션 코드는 다른 애플리케이션이나 핵심 서버의 키를 훔칠 수도 있습니다.

3. FastCGI 기술은 현재 C/C++, Java, Perl, Tcl, Python, SmallTalk, Ruby 등의 언어를 지원합니다. 관련 모듈은 Apache, ISS, Lighttpd와 같은 널리 사용되는 서버에서도 사용할 수 있습니다.

4. FastCGI는 웹 서버의 내부 아키텍처에 의존하지 않으므로 서버 기술이 변경되더라도 FastCGI는 안정적으로 유지됩니다.

다중 프로세스이기 때문에 CGI 다중 스레딩보다 더 많은 서버 메모리를 사용합니다. PHP-CGI 인터프리터는 프로세스당 7~25MB의 메모리를 사용합니다. 이 숫자에 50 또는 100을 곱하면 많은 양의 메모리를 얻을 수 있습니다.

Nginx 0.8.46+PHP 5.2.14(FastCGI) 서버에는 30,000개의 동시 연결이 있습니다. 시작된 10개의 Nginx 프로세스는 150M 메모리(15M*10=150M)를 소비하고 64개의 php-cgi 프로세스는 1280M 메모리(20M)를 소비합니다. *64=1280M), 시스템 자체에서 소비하는 메모리를 더하면 총 메모리 소비는 2GB 미만입니다. 서버 메모리가 작을 경우 25개의 php-cgi 프로세스만 열 수 있으므로 php-cgi에서 소비하는 총 메모리는 500M에 불과합니다.

위 데이터는 Apache(버전 6)보다 10배 향상된 웹 서버를 구축하기 위해 Nginx 0.8.x + PHP 5.2.13(FastCGI)에서 발췌한 것입니다.

원리:

1. 웹 서버가 시작되면 FastCGI 프로세스 관리자를 로드합니다.

2. FastCGI 프로세스 관리자는 여러 CGI 인터프리터 프로세스(PHP-CGI)를 시작하고 웹 서버로부터의 연결을 기다립니다.

3. 클라이언트 요청이 웹 서버에 도달하면 FastCGI 프로세스 관리자가 CGI 인터프리터를 선택하여 연결하고 웹 서버는 CGI 환경 변수와 표준 입력을 FastCGI 하위 프로세스 PHP-CGI로 보냅니다.

4. FastCGI 하위 프로세스는 처리를 완료한 후 동일한 연결에서 웹 서버로 표준 출력 및 오류 정보를 반환합니다. FastCGI 하위 프로세스가 연결을 닫으면 요청이 처리됩니다. 그런 다음

FastCGI

하위 프로세스는 FastCGI프로세스 관리자(웹 서버에서 실행)의 다음 연결을 기다리고 처리합니다. CGI 모드에서는 PHP-CGI가 여기서 종료됩니다. 위 상황에서 일반적으로 CGI가 얼마나 느린지 상상할 수 있습니다. PHP에 대한 모든 웹 요청은 php.ini를 다시 구문 분석하고, 모든 확장을 다시 로드하고, 모든 데이터 구조를 다시 초기화해야 합니다. FastCGI를 사용하면 이 모든 작업이 프로세스가 시작될 때 한 번만 발생합니다. 또한 데이터베이스 영구 연결이 작동합니다.

참고:

FastCGI의 가장 큰 장점은 HTTP 서버에서 동적 언어를 분리하는 것입니다. 따라서 Nginx와 PHP/PHP-FPM은 프론트 엔드 Nginx 서버에 대한 압력을 공유하기 위해 종종 다른 서버에 배포되므로 Nginx는 독점적으로 정적 요청을 처리하고 동적 요청을 전달하며, PHP/PHP-FPM 서버는 PHP 동적 요청을 독점적으로 구문 분석합니다.

3), PHP-CGI

PHP-CGI는 PHP와 함께 제공되는 FastCGI 관리자입니다.

PHP-CGI의 단점:

1. php-cgi에서 php.ini 구성을 변경한 후 새로운 php-ini를 적용하려면 php-cgi를 다시 시작해야 하며 원활한 다시 시작이 불가능합니다.

2. php-cgi 프로세스를 직접 종료하면 php가 실행될 수 없습니다(PHP-FPM 및 Spawn-FCGI에는 이 문제가 없으며 데몬 프로세스는 새 하위 프로세스를 원활하게 재생성합니다).

4), Spawn-FCGI

Spawn-FCGI는 lighttpd의 일부입니다. 그러나 많은 사람들이 FastCGI 모드에서 관리 작업을 수행하는데 많은 단점이 있습니다. PHP-FPM의 출현으로 일부 문제가 다소 완화되었지만 PHP-FPM의 한 가지 단점은 다시 컴파일해야 한다는 것입니다. 이는 이미 실행 중인 일부 환경에 상당한 위험을 초래할 수 있습니다(참조). PHP는 PHP 5.3에서 직접 사용할 수 있습니다. 3 -FPM.

Spawn-FCGI는 이제 별도의 프로젝트가 되어 더 안정적이고 많은 웹 사이트 구성에 편리함을 제공합니다. 많은 사이트에서 동적 웹 페이지를 해결하기 위해 nginx와 페어링했습니다. 최신 lighttpd에는 이 부분이 포함되어 있지 않지만(http://www.lighttpd.net/search?q=Spawn-FCGI) 이전 버전에서 찾을 수 있습니다. lighttpd-1.4.15

버전(http://www.lighttpd.net/download/lighttpd-1.4.15.tar.gz)에 포함되어 있습니다. 현재 Spawn-FCGI 다운로드 주소는 http://입니다. redmine .lighttpd.net/projects/spawn-fcgi, 최신 버전은 http://www.lighttpd.net/download/spawn-fcgi-1.6.3.tar.gz입니다.

참고:

최신 Spawn-FCGI의 경우 lighttpd.net 웹사이트에서 "Spawn-FCGI"를 검색하여 최신 버전 릴리스 주소를 찾을 수 있습니다.

5) Spawn-FCGI

PHP-FPM에 비해 사용이 매우 편리합니다. 구성은 PHP-FPM.ini 파일에 있으며, 시작 및 재시작은 php/sbin/PHP-FPM에서 수행할 수 있습니다. 더 편리한 점은 php.ini를 수정한 후 PHP-FPM 다시 로드를 사용하여 직접 로드할 수 있다는 점입니다. 프로세스를 종료하지 않고도 php.ini의 수정 및 로드를 완료할 수 있다는 점은 PHP-FPM을 사용하면 상당한 이점을 얻을 수 있다는 것을 보여줍니다. PHP의 성능을 향상시킵니다. PHP-FPM으로 제어되는 프로세스의 CPU 재활용 속도는 상대적으로 느리고, 메모리는 균등하게 할당됩니다.

Spawn-FCGI가 제어하는 ​​프로세스의 CPU가 빠르게 저하되고 메모리 할당이 고르지 않습니다. 할당되지 않은 것처럼 보이는 많은 프로세스가 있고 다른 프로세스는 많이 사용되고 있습니다. 이는 프로세스 작업의 고르지 못한 분포로 인해 발생할 수 있습니다. 이는 또한 전체 응답 속도의 감소로 이어집니다. PHP-FPM의 합리적인 분포는 전반적인 응답과 작업의 평균에 대한 언급으로 이어집니다.

2. Nginx+PHP 구성

1. 프로세스 수 최적화

pm = 동적

pm.max_children = 300

pm.start_servers = 20

pm.min_spare_servers = 5

pm.max_spare_servers = 35

2. 최대 요청 수 최적화

pm.max_requests = 10240

참고:

이는 PHP 파서 또는 참조된 타사 라이브러리로 인해 발생하는 메모리 누수를 처리하는 데 사용됩니다.

최대 요청 수: php-fpm 작업자 프로세스가 처리 후 종료되는 요청 수를 나타냅니다.

3. 최대 실행 시간 최적화(php.ini)

request_terminate_timeout = 20

참고:

PHP 실행 시간이 너무 길어서

502

error이 보고되는 문제를 해결하는 데 사용됩니다. 이 기간 구성은 php.ini(max_execution_time) 또는 php-fpm.conf에서 구성할 수 있으며, 전역 구성에 영향을 주지 않기 위해 php-fpm.conf에서 구현할 수 있습니다.

nginx.conf에서 max_fail(확대) 및 failure_timeout(더 작게 향상)과 함께 구성해야 한다는 점은 주목할 가치가 있습니다.

nginx.conf:

위치 ~ .php$ {

…

fastcgi_connect_timeout 180;

fastcgi_read_timeout 600;

fastcgi_send_timeout 600;

}

참고:

PHP-FPM 설정 스크립트의 최대 실행 시간은 충분히 길지만 시간이 많이 걸리는 PHP 스크립트를 실행하면 Nginx 오류

가 504

오류로 변경되는 것을 발견했습니다. 이는 우리가 PHP 구성만 수정했고 Nginx에도 업스트림 서버와의 통신 시간 초과와 관련된 사실cgi_connect/read/send_timeout 구성이 있기 때문입니다.

4. php-fpm 높은 CPU 사용량 문제 해결

top 명령:

top 명령을 직접 실행한 후 1을 입력하여 각 코어의 CPU 사용량을 확인합니다.

sar 명령:

sar 및 설치 iostat 명령 중:

sysstat.x86_64: sar 및 iostat systemmonitoring 명령

yum install -y sysstat.x86_64

실행:

$sar -P ALL 1 100

참고:

-P ALL은 모두 모니터를 의미합니다. 코어; 1 초마다 수집하는 것은 100 번을 수집합니다. :

위는 php-fpm을 켠 느린 로그이며, 시간 임계값은 2초입니다.

실행:

grep -v "^$" php.slow.log cut -d " " -f 3,2 | sort |uniq -c | sort -k1,1nr | head -n 50

참고:

정렬: 단어 정렬

uniq -c: 고유한 줄을 표시하고 각 줄의 시작 부분에 이 줄을 추가합니다. file 횟수

Sort -k1,1nr: 첫 번째 필드, 값 및 역순으로 정렬

Head –n 10: 데이터의 처음 10행 가져오기

PS:

켜는 목적 느린 로그는 PHP 스크립트의 실행 시간이 설정된 request_slowlog_timeout을 초과하는지 추적하고 분석하는 것입니다.

3. Php-Fpm 작업

PHP5.3.3의 php-fpm은 이전에 php-fpm에 필요했던 /usr/local/php/sbin/php-fpm (start|stop|reload)와 ​​같은 명령을 더 이상 지원하지 않습니다. 신호 제어를 사용하려면:

마스터 프로세스는 다음 신호를 이해할 수 있습니다.

QUIT 원활하게 종료

USR2는 모든 작업자 프로세스를 원활하게 다시 로드하고 구성 및 바이너리를 다시 로드합니다. 모듈;

예:

php-fpm 종료: kill -INT`cat /usr/local/php/var/run/php-fpm.pid`

php-fpm 다시 시작: kill -USR2`cat /usr / local/php/var/run/php-fpm.pid`

php-fpm 프로세스 수 보기:

$ps aux | grep -c php-fpm

권장 학습: "

PHP 비디오 튜토리얼

"

위 내용은 1분 만에 PHP-FPM 구성 및 사용 요약 이해의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!