PHP-fpm配置文件PHP-fpm.conf路径为/usr/local/php/etc/php-fpm.conf
如何修改php-fpm设置？使用vi命令编辑配置文件，然后重新加载或重启php-fpm即可，命令如下
1 | vi /usr/local/php/etc/php-fpm.conf |
里面比较重要的配置项有如下一些。
1 2 3 4 5 6 7 8 9 | request_terminate_timeout = 30 #表示等待30秒后，结束那些没有自动结束的php脚本，以释放占用的资源。 pm表示使用那种方式，就是static（静态）或者dynamic（动态）。在更老一些的版本中，dynamic被称作apache-like。 pm.max_children：静态方式下开启的php-fpm进程数量。 pm.start_servers：动态方式下的起始php-fpm进程数量。 pm.min_spare_servers：动态方式下的最小php-fpm进程数量。 pm.max_spare_servers：动态方式下的最大php-fpm进程数量。 |
如果dm设置为static，那么其实只有pm.max_children这个参数生效，系统会开启设置数量的php-fpm进程。
如果dm设置为dynamic，那么pm.max_children参数失效，后面3个参数生效。
系统会在php-fpm运行开始 的时候启动pm.start_servers个php-fpm进程，然后根据系统的需求动态在pm.min_spare_servers和pm.max_spare_servers之间调整php-fpm进程数。
那么，对于我们的服务器，选择哪种执行方式比较好呢？事实上，跟Apache一样，运行的PHP程序在执行完成后，或多或少会有内存泄露的问题。这也是为什么开始的时候一个php-fpm进程只占用3M左右内存，运行一段时间后就会上升到20-30M的原因了。
对于内存大的服务器（比如8G以上）来说，指定静态的max_children实际上更为妥当，因为这样不需要进行额外的进程数目控制，会提高效率。
因为频繁开关php-fpm进程也会有时滞，所以内存够大的情况下开静态效果会更好。数量也可以根据 内存/30M 得到，比如8GB内存可以设置为100，那么php-fpm耗费的内存就能控制在 2G-3G的样子。如果内存稍微小点，比如1G，那么指定静态的进程数量更加有利于服务器的稳定。这样可以保证php-fpm只获取够用的内存，将不多的 内存分配给其他应用去使用，会使系统的运行更加畅通。
对于小内存的服务器来说，比如256M内存的VPS，即使按照一个20M的内存量来算，10个php-cgi进程就将耗掉200M内存，那系统的崩溃就应该很正常了。
因此应该尽量地控制php-fpm进程的数量，大体明确其他应用占用的内存后，给它指定一个静态的小数量，会让系统更加平稳一些。
或者使用动态方式，因为动态方式会结束掉多余的进程，可以回收释放一些内存，所以推荐在内存较少的服务器或VPS上使用。
php-fpm最大数量根据 内存/20M 得到。
查看当前系统每个php-fpm进程平均消耗的内存量命令
1 | ps --no-headers -o "rss,cmd" -C php-fpm | awk '{ sum+=$1 } END { printf ("%d%s\n", sum/NR/1024,"M") }' |
比如1G内存（1024M）的VPS或者云主机，应该设置为dynamic动态方式，建议pm.max_spare_servers设置为20。至于pm.min_spare_servers，则建议根据服务器的负载情况来设置，比较合适的值在5~10之间（并发访问较大则应设置较大）。
1 | pm.max_requests = 2000 |
#设置每个子进程重生之前服务的请求数. 对于可能存在内存泄漏的第三方模块来说是非常有用的. 如果设置为 ’0′ 则一直接受请求. 等同于 PHP_FCGI_MAX_REQUESTS 环境变量. 默认值: 0.—这个根据个人需求来决定要不要设置pm.max_requests值
2018.3.29
2018.3.29 补充内容:
PHP的pm、pm.max_requests、memory_limit参数该如何设置?
1、php-fpm.conf中的pm
pm是来控制php-fpm的工作进程数到底是一次性产生固定不变（static）还是在运行过程中随着需要动态变化（dynamic）。众所周知，工作进程数与服务器性能息息相关，太少则不能及时处理请求，太多则会占用内存过大而拖慢系统。因为php-fpm处理请求时会随着处理的请求数的增加而占用越来越多的内存，所以static模式下往往不好判断启动的能使内存利用最大化的固定进程数，所以想到了dynamic模式。可是为什么我们不用dynamic模式呢，试想某个时刻请求数比较低，20个进程足够应付，突然压力增大了，出现了40个并发PHP请求，按照最小5个空闲进程的设置就需要45个进程，也就是说需要在短时间内创建出25个进程，我们知道创建进程的操作是比较消耗系统资源的，再加上40个并发PHP请求肯定也会给MySQL带来一定的压力，此时再创建25个进程无疑是雪上加霜，所以我在这里还是选择了static模式。
2、php-fpm.conf中的pm.max_requests
根据说明我们知道这个参数的含义是php-fpm工作进程处理完多少请求后自动重启，主要目的就是为了控制请求处理过程中的内存溢出，使得内存占用在一个可接受的范围内。从这里我们感觉这个数字似乎设置的小一点更加有利于性能提升，但是当这个数字非常小的时候会发生一种情况，由于PHP请求是平均地分配给各个工作进程的，如果这个值太小就会导致所有的工作进程几乎同时达到这个值并且进入需要重启的状态，当所有的工作进程都在同一时刻重启就会发生在数秒内甚至更长的时间PHP将停止响应直到所有的进程均重启完为止。这是不能接受的，所以我一般会把这个值设置为PHP启动后第一批工作进程达到此值需要重启时，第一个进程重启与最后一个进程重启之间的时间相差1分钟以上，一般在压力比较大的晚上这个差值将会扩大到5分钟左右，此时对进程重启对服务器的负面影响就可以忽略了。
3、php.ini中的memory_limit
顾名思义，这个值是用来限制PHP所占用的内存的，具体一点说就是一个PHP工作进程即php-fpm所能够使用的最大内存，默认是128MB，一开始在虚拟机中我设置为PHP 5.1.6的默认值16MB，发现大于16MB的附件将无法下载，也就是说PHP 5.3中附件是从硬盘完整读取到PHP内存中再传给nginx的，这跟PHP 5.1.6+Apache 2.2.3不同，后者读取附件是PHP并不加载这个附件而是直接交给Apache来加载，这就使得php-fpm占用内存大了不少。当php-fpm占用内存达到了memory_limit所限制的值时，当前进程会被fpm主进程使用TERM信号终止掉，此时被处理的PHP请求将返回客户端502错误，nginx的error log中将记录出错原因是“Connection reset by peer”。可是更加令人难以理解的事情发生了，在使用了eAccelerator的PHP 5.3上，居然发生了当php-fpm内存达到memory_limit所限制的值时，所有进程都开始疯狂重启而不再接受任何请求，此时除非使用kill命令杀死主进程，否则php-fpm永远都不会恢复响应，可想而知nginx必然出现无止境的502错误了。。。
评论0