PHP的pm、pm.max_requests、memory_limit参数优化说明

PHP的pm、pm.max_requests、memory_limit参数优化说明
1、php-fpm.conf中的pm
2、php-fpm.conf中的pm.max_requests
3、php.ini中的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错误