기사 디렉토리
서버가 동시에 처리할 수 있는 사용자 수는 서버의 코어 개수가 아니라 각 프로세스가 사용하는 메모리 양에 따라 결정됩니다.
이 말이 다소 도발적으로 들릴 수도 있겠지만, 이는 운영 및 유지보수 업계에서 가장 현실적이고 고통스러운 경험입니다.
메모리가 주요 병목 현상인 이유는 무엇일까요?
많은 사람들이 8코어 CPU와 24GB 메모리를 갖춘 VPS를 보면 무의식적으로 수백 개의 PHP-FPM 프로세스를 쉽게 실행할 수 있을 거라고 생각합니다.
하지만 실제로는 단일 PHP 프로세스의 RSS 메모리 사용량이 200MB에 달하는 경우가 많습니다.
이는 명령줄을 통한 실제 테스트에서 얻은 결과입니다.
ps --no-headers -o rss -p $(pgrep php-fpm) | awk '{sum+=$1} END {print sum/NR/1024 " MB"}'
HestiaCP 의 복잡한 프레임워크와 다중 플러그인 환경, 특히 OPcache 최적화가 없는 경우 200MB는 일반적인 수준입니다.
즉, 최대 동시 처리 용량을 결정하는 것은 CPU가 아니라 메모리라는 것이 핵심적인 한계입니다.
권장 설정 파일(php-fpm.conf)
pm = dynamic
pm.max_children = 80
pm.start_servers = 16
pm.min_spare_servers = 8
pm.max_spare_servers = 24
pm.max_requests = 500
pm.process_idle_timeout = 10s
request_terminate_timeout = 60s
매개변수 계산 논리 및 설정 기준
| 구성 매개변수 | 설정값 | 핵심 계산 및 설정 기준 |
|---|---|---|
| pm | dynamic | 동적 모드는 동시성 요구 사항에 따라 프로세스를 유연하게 추가하거나 삭제할 수 있도록 하여 응답 속도와 메모리 사용률 간의 균형을 유지합니다. |
| pm.max_children | 80 | 시스템 커널을 제외한 총 메모리는 24GB입니다. MySQL의/RedisNginx를 설치하고 나면 PHP에 약 16GB가 남습니다.16,384 MB / 200 MB ≈ 81.9이 값을 80으로 설정하면 동시 접속자가 많을 때 발생하는 메모리 부족(OOM) 오류를 완전히 방지할 수 있습니다. |
| 오후 서버 시작 | 16 | 시작 시 예열은 CPU 코어 수의 두 배(8코어 × 2 = 16)로 설정되어 서비스가 재시작 후 즉시 기본적인 동시 처리를 할 수 있도록 합니다. |
| 오후 최소 예비 서버 | 8 | CPU 코어 수를 8개로 설정하면 트래픽이 적은 시간대에도 언제든지 새로운 요청에 응답할 수 있습니다. |
| 오후 최대 예비 서버 | 24 | 트래픽이 감소한 후에도 적절한 수의 프로세스를 유지하여 완만한 변동에 대응할 수 있도록 CPU 코어 수의 3배(8코어 × 3 = 24)로 설정하십시오. |
| pm.max_requests | 500 | 단일 프로세스가 200MB라는 큰 기본 메모리 사용량에 도달하는 경우, 삭제 및 재구축 전에 요청 수를 500개로 줄이면 암묵적인 메모리 누수를 더 빠르게 해결할 수 있습니다. |
| pm.process_idle_timeout | 10s | 超出 min_spare_servers 유휴 프로세스는 10초 동안 요청이 없으면 자동으로 해제되어 시스템 메모리로 반환됩니다. |
필수 지원 설정 및 최적화 제안
1. 타임아웃 숙취 방지 메커니즘
request_terminate_timeout = 60s 그게 핵심이에요.
이 기능은 데이터베이스 교착 상태 또는 타사 API 차단으로 인해 멈춘 프로세스를 강제로 종료할 수 있습니다.
한편, Nginx의 fastcgi_read_timeout 최소 60초 동안 유지해야 하며, 그렇지 않으면 클라이언트가 메시지를 너무 일찍 받게 됩니다. 504 Gateway Timeout.
2. 메모리 병목 현상을 극복하기 위한 전략
최대 80개의 동시 프로세스는 시스템이 극심한 동시 접속 상황에서 최대 80개의 동적 HTTP 요청을 동시에 처리할 수 있음을 의미합니다.
용량을 더욱 향상시키려면 프로세스별 메모리 사용량을 줄이는 데 집중해야 합니다.
- OPcache 활성화: 在
php.ini중간 구성opcache.enable=1及opcache.memory_consumption=256바이트코드 캐싱을 사용하면 단일 프로세스의 메모리 사용량을 200MB에서 60~100MB로 줄일 수 있습니다. - 메모리 제한에 대한 적절한 제어：将
php.ini가운데memory_limit제한됨128M或256M개별적인 비정상 스크립트를 방지하기 위해无限메모리를 많이 사용합니다.
단일 프로세스의 메모리 사용량이 100MB로 떨어지면...pm.max_children 안전하게 업그레이드할 수 있습니다. 150 또한 동시 접속 처리 능력이 거의 두 배로 증가했습니다.
권위 있는 견해 인용
Nginx 공식 문서 의 권장 사항 에 따르면 다음과 같습니다.
"FastCGI 애플리케이션은 리소스 고갈을 방지하기 위해 항상 타임아웃 지시문을 사용하여 모니터링해야 합니다."
(출처: Nginx 문서)
PHP 공식 매뉴얼에는 다음 과 같이 명시되어 있습니다.
"pm.max_children은 생성될 자식 프로세스의 최대 개수를 정의합니다. 이는 가장 중요한 지시어입니다."
(출처: PHP-FPM 문서)
이러한 권위 있는 견해는 우리의 실제 관행과 완벽하게 일치하며, 최적화 논리가 경험뿐 아니라 표준화된 모범 사례에도 기반한다는 것을 입증합니다.
결론: 나의 견해 및 주요 인용문
동시 접속량이 많은 시나리오에서 CPU는 엔진이고, 메모리는 연료 탱크이며, PHP-FPM은 시스템 운영 관리자 역할을 합니다.
엔진 출력이 아무리 강력해도 연료 탱크가 충분히 크지 않으면 호송대는 멀리 갈 수 없습니다.
진정한 전문가들은 매개변수를 맹목적으로 최대치로 설정하는 것이 아니라, 낭비와 오버플로를 방지하기 위해 각 프로세스의 메모리 사용량을 정확하게 계산합니다.
최적화의 핵심은 제한된 자원으로 최적의 균형을 찾는 것입니다.
이것은 단순한 기술이 아니라 철학 이기도 합니다.
그러므로 "코어 개수가 모든 것을 결정한다"는 생각을 버리세요. 실제로 동시 실행 제한을 결정하는 것은 메모리 제어 능력입니다.
지금 바로 조치를 취하여 VPS를 최대한 최적화하고 메모리 한 방울도 낭비하지 않고 활용하세요.
Chen Weiliang의 블로그( https://www.chenweiliang.com/ ) 에 공유된 "8코어 24G VPS 메모리 부족 문제? HestiaCP에서 PHP-FPM 프로세스 풀의 극한 튜닝"이라는 글이 도움이 되기를 바랍니다.
이 기사 링크( https://www.chenweiliang.com/cwl-34509.html )를 자유롭게 공유해 주세요.