Менеджер процессов FastCGI (FPM)


FPM (Менеджер процессов FastCGI) является альтернативной реализацией PHP FastCGI с несколькими дополнительными возможностями обычно используемыми для высоконагруженных сайтов.

Эти возможности включают в себя:

  • продвинутое управление процессами с корректной (graceful) процедурой остановки и запуска;

  • возможность запуска воркеров с различными uid/gid/chroot-окружением, а также запуска на различных портах с использованием разных php.ini (замещение safe_mode);

  • логирование стандартных потоков вывода (stdout) и ошибок (stderr);

  • аварийный перезапуск в случае внезапного разрушения opcode-кэша;

  • поддержка ускоренной загрузки (accelerated upload);

  • "slowlog" - логирование необычно медленно выполняющихся скриптов (не только их имена, но также и их трассировки. Это достигается с помощью ptrace и других подобных утилит для чтения данных исполнения удаленных процессов);

  • fastcgi_finish_request() - специальная функция для завершения запроса и сброса всех буферов данных, причем процесс может продолжать выполнение каких-либо длительных действий (конвертирование видео, обработка статистики и т.п.);

  • Динамическое/статическое порождение дочерних процессов;

  • Базовая информация о статусе SAPI (аналогично Apache mod_status);

  • Конфигурационный файл, основанный на php.ini.


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.:

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.
2010-12-12 12:05:44
the fpm process supports the USER2 signal, which is used to reload the config file.

kill -USR2 [pid]

should do the trick.
2011-06-30 15:56:07
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
2013-04-26 01:04:08
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!


To enable error logging for the default [www] worker pool, add this line in the [www] section of your php-fpm.conf:

catch_workers_output = yes
2014-05-16 18:17:34
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).
2017-10-04 21:15:56
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.


This is the origin nginx conf.
location ~ \.php$ {
    try_files  $uri = 404;
    fastcgi_index  index.php;
    include  fastcgi.conf;

You can replace it by
upstream php {

location ~ \.php$ {
    try_files  $uri = 404;
    fastcgi_pass  php;
    fastcgi_index  index.php;
    include  fastcgi.conf;


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.

2017-11-21 11:23:15
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 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.
2018-02-28 13:45:58

    Поддержать сайт на родительском проекте КГБ