FastCGI 进程管理器（FPM）
目录
FPM（FastCGI 进程管理器）用于替换 PHP FastCGI 的大部分附加功能，对于高负载网站是非常有用的。
它的功能包括：
-
支持平滑停止/启动的高级进程管理功能；
-
可以工作于不同的 uid/gid/chroot 环境下，并监听不同的端口和使用不同的 php.ini 配置文件（可取代 safe_mode 的设置）；
-
stdout 和 stderr 日志记录;
-
在发生意外情况的时候能够重新启动并缓存被破坏的 opcode;
-
文件上传优化支持;
-
"慢日志" - 记录脚本（不仅记录文件名，还记录 PHP backtrace 信息，可以使用 ptrace或者类似工具读取和分析远程进程的运行数据）运行所导致的异常缓慢;
-
fastcgi_finish_request() - 特殊功能：用于在请求完成和刷新数据后，继续在后台执行耗时的工作（录入视频转换、统计处理等）；
-
动态／静态子进程产生；
-
基本 SAPI 运行状态信息（类似Apache的 mod_status）；
-
基于 php.ini 的配置文件。
add a note
User Contributed Notes 8 notes
robin at robinwinslow dot co dot uk ¶
11 years ago
Init script setup
===
You will probably want to create an init script for your new php-fpm. Fortunately, PHP 5.3.3 provides one for you, which you should copy to your init directory and change permissions:
$ cp <php-5.3.3-source-dir>/sapi/fpm/init.d.php-fpm.in /etc/init.d/php-fpm
$ chmod 755 /etc/init.d/php-fpm
It requires a certain amount of setup. First of all, make sure your php-fpm.conf file is set up to create a PID file when php-fpm starts. E.g.:
----
pid = /var/run/php-fpm.pid
----
(also make sure your php-fpm user has permission to create this file).
Now open up your new init script (/etc/init.d/php-fpm) and set the variables at the top to their relevant values. E.g.:
---
prefix=
exec_prefix=
php_fpm_BIN=/sbin/php-fpm
php_fpm_CONF=/etc/php-fpm.conf
php_fpm_PID=/var/run/php-fpm.pid
---
Your init script is now ready. You should now be able to start, stop and reload php-fpm:
$ /etc/init.d/php-fpm start
$ /etc/init.d/php-fpm stop
$ /etc/init.d/php-fpm reload
The one remaining thing you may wish to do is to add your new php-fpm init script to system start-up. E.g. in CentOS:
$ /sbin/chkconfig php-fpm on
===========
Disclaimer: Although I did just do this on my own server about 20 mins ago, everything I've written here is off the top of my head, so it may not be 100% correct. Also, allow for differences in system setup. Some understanding of what you are doing is assumed.
kokushibyou at gmail dot com ¶
9 years ago
PHP-FPM is FAST - but be wary of using it while your code base is stored on NFS - under average load your NFS server will feel some serious strain. I have yet to find a work around for this bug: https://bugs.php.net/bug.php?id=52312
info at f1-outsourcing dot eu ¶
3 years ago
It looks like the php-fpm daemon is not able to use its groups it is running with.
https://bugs.php.net/bug.php?id=77837
ganlvtech at qq dot com ¶
4 years ago
php-fpm is not avaliable on Windows, but you can use IIS or Apache as the "fastcgi process manager".
If you have to use Nginx, here is a solution. Nginx provides a load balancing module. We can distribute the request to different php-cgi.exe process.
<http://nginx.org/en/docs/http/load_balancing.html>
<http://nginx.org/en/docs/http/ngx_http_upstream_module.html>
This is the origin nginx conf.
```
location ~ \.php$ {
try_files $uri = 404;
fastcgi_pass 127.0.0.1:9000;
fastcgi_index index.php;
include fastcgi.conf;
}
```
You can replace it by
```
upstream php {
server 127.0.0.1:9000;
server 127.0.0.1:9001;
server 127.0.0.1:9002;
server 127.0.0.1:9003;
}
location ~ \.php$ {
try_files $uri = 404;
fastcgi_pass php;
fastcgi_index index.php;
include fastcgi.conf;
}
```
CAUTION!!
php-cgi.exe process will die after several requests, so you have to restart the php-cgi.exe manually to keep a process listening the port.
DON'T USE THIS SOLUTION IN PRODUCTION!!
user at NOSPAM dot example dot com ¶
4 years ago
It is important to note that FPM is not built with the windows binaries. Many of the guides you may find online rely on php-cgi.exe. Unfortunately they call it FPM but this is incorrect!
The executable php-cgi.exe that is bundled with the windows binaries is a FastCGI interface but it is *not* FPM (Fastcgi Process Manager). php-cgi.exe does not have multi-threading or concurrent request support, nor support for any of the FPM configuration options.
The only solid information I've gathered into why FPM is not available is a bug report explaining that FPM is built around fork(), which is not natively available on windows (https://bugs.php.net/bug.php?id=62447).
joel k ¶
10 years ago
the fpm process supports the USER2 signal, which is used to reload the config file.
kill -USR2 [pid]
should do the trick.
dreamcat4 at gmail dot com ¶
8 years ago
Doesn't work? Enable logging!
The php-fpm.log file is a great place to fault-find errors and get to the bottom of a problem. But be sure to enable logging for your specific worker pool. Or you won't see anything!
Example:
To enable error logging for the default [www] worker pool, add this line in the [www] section of your php-fpm.conf:
[www]
catch_workers_output = yes
ikrabbe dot ask at gmail dot com ¶
4 years ago
I'm very unhappy with the way php-fpm handles requests.
There isn't even some SCRIPT_FILENAME in the RFC for CGI, an that's the only standard I found to handle the requests.
Actually what you are doing with PATH_TRANSLATED is supposed to translate to the path, which is broken by media wikis, as they use the PATH_INFO to find the ressource, not some script.
In the original CGI context, the PATH_INFO is passed to the CGI binary to specify some ressource argument. So actually
SCRIPT_NAME ~ argv0
PATH_INFO ~ argv1
in command context.
Conclusion: We should rewrite php-fpm to obey the rfc3875 CGI standard.
Having SCRIPT_NAME pointing to /something.php, must translate to
CWD/something.php
CWD is the working directory where php-fpm is started (or configured to change to).
In case of chroot CWD = "".
In any case the SCRIPT_NAME php script can be found with ./SCRIPT_NAME, from the CWD. So the undocumented not standardized SCRIPT_FILENAME should vanish! It breaks the CGI standard.