|
1. Unix 도메인 소켓 통신 이전에 Unix 도메인 소켓 통신 방법을 간략하게 소개한 적이 있습니다. Nginx+PHP-FPM의 도메인 소켓 구성 방법 Unix 도메인 소켓은 Nginx와 php-fpm 간 통신을 거치지 않기 때문에 실제로 통신 성능을 향상시킬 수 있습니다. 하지만 동시성이 높으면 불안정해집니다. Nginx는 다음과 같은 오류를 자주 보고합니다. connect() to unix:/dev/shm/php-fcgi .sock이 업스트림에 연결하는 동안 실패했습니다(11: 리소스를 일시적으로 사용할 수 없음) 다음 두 가지 방법으로 안정성을 향상할 수 있습니다. 1) nginx 및 php-fpm에서 백로그를 늘립니다.구성 방법은 nginx 구성 파일에서 이 도메인 이름의 서버 아래에 Listen 80 이후 기본 backlog=1024를 추가하는 것입니다. 동시에 php-fpm.conf의 listening.backlog를 1024로 구성하고 기본값은 128입니다. 2) 양말 파일 수 및 php-fpm 인스턴스 수 늘리기 Nginx에서 새 양말 파일 만들기 업스트림 모듈을 사용하여 두 개의 양말 파일 뒤에 있는 두 개의 php-fpm 인스턴스 세트에 대한 요청을 로드 밸런싱합니다. 2.php-fpm 매개변수 조정 2.1 프로세스 수 php-fpm 초기/유휴/최대 작업자 프로세스 수 pm.max_children = 300 pm.start_servers = 20 pm.min_spare_servers = 5 pm.max_spare_servers = 35
2.2 최대 처리 요청 수 최대 처리 요청 수는 php 기준입니다. -fpm 작업자 여러 요청을 처리한 후 프로세스가 종료되고 마스터 프로세스 가 새 프로세스를 다시 생성합니다. 이 구성의 주요 목적은 PHP 인터프리터 또는 프로그램에서 참조하는 타사 라이브러리로 인해 발생하는 으로 인한 메모리 누수를 방지하는 것입니다. . pm.max_requests = 10240 2.3 최대 실행 시간 최대 실행 시간은 php.ini와 php-fpm.conf에서 각각 설정 가능하며, 설정 항목은 각각 max_execution_time과 request_terminate_timeout입니다. 역할 및 영향은 다음을 참조하세요. Nginx의 502 및 504 오류에 대한 자세한 설명 3. php-fpm의 높은 CPU 사용량 문제 해결 방법 3.1CPU 사용량 모니터링 방법 1) top 명령 top 명령을 직접 실행한 후 1을 입력하면 각 코어의 CPU 사용량을 확인할 수 있습니다. 그리고 샘플링 시간은 top -d 0.1만큼 단축될 수 있습니다. 아래 sar는 최단 시간으로 1초밖에 안되는 것 같습니다. 2) sar 명령 sar 및 iostat 명령 설치: sysstat.x86_64 : sar 및 iostat 시스템 모니터링 명령 yum install -y sysstat.x86_64 sar -P ALL 1 실행 100. -P ALL은 모든 코어를 모니터링한다는 의미이고, 1은 1초마다 수집을 의미하며, 100은 100회 수집을 의미합니다. 출력 결과는 다음과 같습니다. CPU %user %nice %system %iowait %steal %idle all 85.54 0.00 5.69 0.00 0.00 8.76 0 74.75 0.00 25.25 0.00 0.00 0.00 1 98.00 0.00 2.00 0.00 0.00 0.00 2 89.22 0.00 3.92 0.00 0.00 6.86 3 91.00 0.00 2.00 0.00 0.00 7.00 4 75.00 0.00 9.00 0.00 0.00 16.00 5 9 4.95 0.00 5.05 0.00 0.00 0.00 6 95.00 0.00 4.00 0.00 0.00 1.00 7 87.88 0.00 4.04 0.00 0.00 8.08 8 93.94 0.00 3.03 0.00 0.00 3.03 9 88. 00 0.00 3.00 0.00 0.00 9.00 10 89 .11 0.00 2.97 0.00 0.00 7.92 11 82.35 0.00 3.92 0.00 0.00 13.73 12 73.27 0.00 7.92 0.00 0.00 18.81 13 81.44 0.00 4.12 0.00 0.00 14.43 14 77.23 0.00 6.93 0.00 0.00 15.84 15 78.79 0.00 4.04 0.00 0.00 17.17 3.2 느린 로그 활성화 출력 php-fpm 느린 로그 구성, 임계값은 2초입니다. request_slowlog_timeout = 2 slowlog = log/$pool.log.slow sort/uniq 명령을 사용하여 다음을 수행합니다. php-fpm 느린 로그 분석 및 요약: [root@b28-12 log]# grep -v "^$" www.log.slow.tmp | cut -d " " -f uniq | -c | sort -k1,1nr | head -n 50 5181 run() /www/test.net/framework/web/filters/CFilter.php:41 5156 filter() /www/test. net/framework/web/filters/CFilterChain .php:131 2670 = /www/test.net/index.php 2636 run() /www/test.net/application/controllers/survey/index.php php:665 2630 액션( ) /www/test.net/application/controllers/survey/index.php:18 2625 실행() /www/test.net/framework/web/actions/CAction. php:75 2605 runWithParams( ) /www/test.net/framework/web/CController.php:309 2604 runAction() /www/test.net/framework/web/filters/CFilterChain.php: 134 2538 run() / www/test.net/framework/web/CController.php:292 2484 runActionWithFilters() /www/test.net/framework/web/CController.php:266 2251 실행() /www/test.net/framework/web/CWebApplication.php:276 1799 번역() /www/test.net/application/libraries/Limesurvey_lang.php:118 1786 load_tables() /www/test.net/application/third_party/php-gettext/gettext.php:254 1447 runController() /www/test.net/framework/web/CWebApplication.php:135 매개변수 설명: sort: 단어 정렬 uniq -c: 고유한 줄을 표시하고 이 줄이 파일의 각 줄 시작 부분에 나타나는 횟수를 추가합니다. sort -k1,1nr: 다음에 따라 첫 번째 필드는 숫자에 따라 역순으로 정렬됩니다. head -10: 데이터의 처음 10행 가져오기 3.3 strace를 사용하여 프로세스 추적 1) nohup을 사용하여 strace 변환 연결 시 php-fpm 프로세스가 종료될 때까지 백그라운드 실행: nohup strace -T -p 13167 > 13167-strace.log & 매개변수 설명: -c는 각 시스템 호출의 실행 시간, 횟수 및 오류 횟수를 계산합니다. 2) 또한 -c 매개변수를 사용하여 strace 도움말을 요약할 수 있는데 이는 매우 편리하고 강력합니다! xcache.mmap_path에 의해 설정된 파일을 열거나 생성할 수 없습니다. 경로 권한을 확인하거나 시스템 제한에 대해 xcache.size/var_size를 확인하세요이것은/tmp/xcache가 파일이며 디렉터리로 생성할 수 없습니다. php-fpm 서비스를 다시 시작한 후 top 명령을 사용하여 각 작업자 프로세스의 VIRT(스왑 영역 포함)가 xcache.size의 크기이지만 REQ가 매우 작아지는 것을 관찰합니다. 위 구성을 사용하면 CPU 사용량이 최고조에 달하는 시간이 단축되었지만, 여전히 최고조에 이르면 모든 코어가 90% 이상에 도달하게 됩니다. 어딘가에 잘못된 구성이 있는지는 모르겠습니다. 또한 동시성이 높을 때 /dev/zero 구성 방법으로 인해 Nginx 502 오류가 발생하는 경우가 많습니다. /tmp/xcache 및 readonly_protection 활성화는 매우 안정적입니다. 4.php 프로그램 성능 모니터링 일반적인 방법은 xdebug의 성능 모니터링 기능을 활성화하고 WinCacheGrind 소프트웨어를 통해 xdebug 출력 결과를 분석하는 것입니다. xdebug 설치 및 IDE 디버깅 방법은 Vim+XDebug PHP 디버깅을 참조하세요 php.ini에 구성되는 항목 출력 성능 정보: xdebug.auto_trace = 켜기 xdebug.auto_profile = 켜기 이런 식으로 XDebug는 모든 실행 PHP 함수 성능 데이터를 출력하지만 생성된 파일은 더 커집니다. Collect_params, Collect_return, 과 같은 일부 옵션을 꺼서 출력 데이터의 양을 줄일 수 있습니다. 또는 자동 출력을 끄고 모니터링하려는 함수의 시작과 끝 부분에서 xdebug 함수를 호출하여 지정된 함수를 모니터링합니다. 출력 파일 이름은 Windows 플랫폼에서 WinCacheGrind를 사용하여 그래픽 분석을 위해 얻을 수 있는 캐시그라인드.out.1277560600 및 추적.3495983249.txt와 유사합니다. WinCacheGrind 사용법은 인터넷에 많이 소개되어 있어서 여기서는 자세히 설명하지 않겠습니다. -c는 각 시스템 호출의 실행 시간, 횟수 및 오류를 계산합니다. -d는 표준 오류에 대한 strace 디버깅 정보를 출력합니다. -f는 포크 호출로 생성된 하위 프로세스를 추적합니다. -o 파일 이름 , 모든 프로세스의 추적 결과가 해당 파일 이름으로 출력됩니다. -F는 vfork 호출을 추적하려고 시도합니다. -f인 경우, -h는 간단한 도움말 정보를 출력합니다. -i 인쇄 시스템 호출의 진입 포인터 -q 분리에 대한 메시지 출력을 비활성화합니다. -r 출력의 각 줄에 대해 각 시스템 호출의 상대 시간을 인쇄합니다. 출력의 각 라인 -tt 출력의 각 라인 앞에 시간 정보를 추가합니다(마이크로초 수준). -ttt 시간을 초 단위로 표시하는 마이크로초 수준 출력 -T 각 라인에 걸리는 시간입니다. -v는 모든 시스템 호출을 출력합니다. 환경 변수, 상태, 입력 및 출력 등에 관한 일부 호출은 빈번한 사용으로 인해 기본적으로 출력되지 않습니다. -x 비표준 문자열을 16진수 형식으로 출력 -xx 모든 문자열을 16진수 형식으로 출력합니다. -a 열 반환 값의 출력 위치를 설정합니다. -e execve execve 와 같은 시스템 호출만 기록합니다.-p 주 프로세스 번호
|
이상 내용의 측면을 포함하여 Nginx PHP-FPM 최적화 기술을 요약해서 소개했습니다. PHP 튜토리얼에 관심이 있는 친구들에게 도움이 되기를 바랍니다.
![[웹 프런트엔드] Node.js 빠른 시작](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
