php-fpm의 max_children 구성 이해

이제 nginx + fpm은 기본적으로 주류 구성이 되었으며, 그 중 pm.max_chindren

우선 설정에 주의를 기울입니다: pm = static/dynamic. pm = static/dynamic。

相关学习推荐：PHP编程从入门到精通

这个选项是标识fpm子进程的产生模式：

static ：表示在fpm运行时直接fork出pm.max_chindren个worker进程

dynamic：表示，运行时fork出start_servers个进程，随着负载的情况，动态的调整，最多不超过max_children个进程。

一般推荐用static，优点是不用动态的判断负载情况，提升性能，缺点是多占用些系统内存资源。

上面的告诉我们max_chindren代表的worker的进程数。普遍认为，这个配置越多能同时处理的并发也就越多，这是一个比较大的误区：

• 1) 其实进程多了，增加进程切换的开销，更核心的是，能并发执行的fpm进程不会超过cpu个数。通过多开worker的个数来提升qps， 是错误的理解，不会说你多开了几个进程，就多出几个cpu来处理。
• 2) worker进程开少了，如果server比较繁忙的话，会导到nginx把数据打到fpm的时候，发现所有的woker都在工作中，没有空闲的worker来接受请求，从而导致502。
• 3) 在实际业务中，由于我们有很多的i/o操作，比如读取数据库，或者内部rpc调用这类在等待i/o的过程中，进程会被系统sleep, 而不占用cpu，如果配置worker少了，也会导致cpu利用不上

那worker数到底该怎么配置呢？

理论上woker进程数=cpu的个数是最合理的，但由于第2点，可能每个worker都没处理完请求，这样，就会频现502了。但多开进程，只是说避免502，暂时把请求hang住，但这只是缓解之道，实际上这不但不会增加系统的并发，而且会加重系统的负荷，所以，基于2，3 ，设置一个合理的worker数就比较重要了。

天下武功，唯快不破，只有尽可能的提升程序的效率，把单个请求的时间压缩到最低，这样，单个worker的处理时间变短了，那在单位时间里能处理的请求自然就多了。

那么可以通过每个worker在单位时间内处理的请求数来预估max_children的个数。假如最大的一个请求的处理时间(xhprof里看cpu时间)是100ms内，而在100ms之内同时有100个请求过来，那了理论上就需要配置100个worker进程，先把请求给hang住。

但最大的请求耗时可能会受很多外在的情况影响，不太好预估，尤其是网络i/o也算在里面，我们可以借用第三方的profile工具，比如xhprof, 这类工具可以统计cpu的耗时，通过这个时间来计算真正的worker数量，比总时间来计算要合理很多，其实这里有一个捷径，来配置你的max_children数， 就是你前期先把max_childnren设置成一个比较大的值，稳定运行一段时间后，观察fpm的status里的 max active processes

관련 학습 권장 사항: PHP 프로그래밍 입문부터 숙련까지 a>🎜

🎜이 옵션은 fpm 하위 프로세스의 생성 모드를 식별하기 위한 것입니다. 🎜🎜static: 은 pm을 직접 분기하는 것을 의미합니다. fpm이 실행 중일 때 max_chindren 작업자 프로세스 🎜🎜dynamic:은 start_servers 프로세스가 로드에 따라 동적으로 조정된다는 의미입니다. , 최대 프로세스는 max_children을 초과하지 않습니다. 🎜🎜일반적으로 정적을 사용하는 것이 좋습니다. 부하 상황을 동적으로 확인할 필요가 없다는 장점이 있고, 시스템 메모리 리소스를 더 많이 차지한다는 단점이 있습니다. 🎜🎜위는 max_chindren이 나타내는 작업자 프로세스 수를 알려줍니다. 일반적으로 이 구성이 동시에 처리할 수 있는 동시성이 많을수록 이는 상대적으로 큰 오해입니다. 🎜

• 1) 실제로 프로세스가 많아지면 프로세스 전환 비용이 더 많이 증가합니다. 중요한 것은 동시에 실행될 수 있는 fpm 프로세스 수가 CPU 수를 초과하지 않는다는 것입니다. 더 많은 작업자를 열어서 QPS를 높이는 것은 잘못된 이해입니다. 더 많은 프로세스를 열면 처리할 CPU가 더 많아진다는 의미는 아닙니다.
• 2) 서버가 사용량이 많으면 nginx가 데이터를 fpm에 도달하게 되며 모든 작업자가 작업 중이고 수락할 유휴 작업자가 없는 것으로 확인됩니다. 요청하면 502가 발생합니다.
• 3) 실제 비즈니스에서는 I/O를 기다리는 동안 데이터베이스 읽기나 내부 RPC 호출 등의 I/O 작업이 많기 때문에 프로세스는 시스템을 점유하지 않고 절전 모드로 전환됩니다. CPU, 워커를 적게 구성하면 CPU를 활용하지 못하게 됩니다

🎜그럼 워커 수는 어떻게 구성해야 할까요? 🎜🎜이론적으로는 Waker 프로세스 수 = CPU 수가 가장 합리적이지만 포인트 2로 인해 각 작업자가 요청 처리를 완료하지 못할 수 있으므로 502가 자주 나타납니다. 하지만 더 많은 프로세스를 여는 것은 502를 방지하고 요청을 일시적으로 중단하는 것을 의미하지만 이는 이를 완화하는 방법일 뿐이며 실제로 시스템의 동시성을 높일 뿐만 아니라 시스템의 부하도 증가시킵니다. 2와 3을 기준으로 합리적인 근로자 수를 설정하는 것이 더 중요합니다. 🎜🎜세상에서 빠를 수 밖에 없는 무술은 프로그램의 효율성을 최대한 높이고, 단일 요청에 소요되는 시간을 최소화하는 것입니다. 단축되므로 당연히 단위 시간당 더 많은 요청을 처리할 수 있습니다. 🎜🎜그러면 max_children 수는 단위 시간당 각 작업자가 처리하는 요청 수로 추정할 수 있습니다. 가장 큰 요청의 처리 시간(xhprof의 CPU 시간)이 100ms 이내이고 100ms 이내에 100개의 요청이 동시에 들어오는 경우 이론적으로 요청을 먼저 정지하려면 100개의 작업자 프로세스를 구성해야 합니다. 🎜🎜그러나 최대 요청 시간은 많은 외부 상황에 의해 영향을 받을 수 있으며 예측하기 어렵습니다. 특히 네트워크 I/O도 포함되어 있습니다. xhprof 등과 같은 타사 프로필 도구를 빌릴 수 있습니다. CPU 시간을 계산할 수 있습니다. 그리고 이 시간을 이용해 실제 작업자 수를 계산하는데, 이는 총 시간보다 훨씬 합리적입니다. 실제로 여기에는 max_children 수를 구성하는 지름길이 있는데, 이는 초기 단계에서 max_children을 상대적으로 큰 값으로 설정하는 것입니다. 일정 시간 동안 안정적으로 실행한 후 fpm 상태에서 max active process를 관찰한 후 max_children을 그보다 크게 설정하면 괜찮습니다. 🎜

위 내용은 php-fpm의 max_children 구성 이해의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!