Home > PHP, PHP-FPM > Cleanest configuration for the new PHP-FPM?

Cleanest configuration for the new PHP-FPM?

August 26th, 2010 Leave a comment Go to comments

When examining the PHP-FPM configuration, I realized that I only tweak a few key pieces per pool, so I decided to share my approach to minimize redundancy and keep things simple (more files, but simpler to manage)

Because I still have to maintain PHP 5.2.x for clients, I have decided to try building everything in self-contained in an /opt/php53 directory. So consider that my $prefix, and change appropriately.

I have the following setup, and it seems to work great so far.


log_level = notice
error_log = /opt/php53/var/log/php-fpm.log
pid = /opt/php53/var/run/php-fpm.pid
emergency_restart_threshold = 10
emergency_restart_interval = 1m
process_control_timeout = 5s
daemonize = yes

; pools
include = /opt/php53/etc/fpm.d/pools/*.conf

One file per pool, for example, a pool named "mike" -


listen =
user = mike
group = mike
request_slowlog_timeout = 5s
slowlog = /opt/php53/var/log/slowlog-mike.log
pm.max_children = 5
pm.start_servers = 3
pm.min_spare_servers = 2
pm.max_spare_servers = 4
pm.max_requests = 500
include = /opt/php53/etc/fpm.d/common.conf

Common elements for each pool (if these could be inherited globally, which they MIGHT be, I could just toss them in the main php-fpm.conf. Perhaps a feature request. Will post on the mailing list...)

Remember that rlimit_files needs to be something set in your sysctl.conf or on the system level or you'll get that RLIMIT_NOFILE warning. Also, depending on how you want to limit resources per pool/client, you may want to tweak things, such as request_terminate_timeout.


listen.backlog = -1
listen.allowed_clients =
pm = dynamic
pm.status_path = /status
ping.path = /ping
ping.response = pong
request_terminate_timeout = 120s
rlimit_files = 131072
rlimit_core = unlimited
catch_workers_output = yes
env[PATH] = /bin:/usr/bin:/usr/local/bin:/usr/local/sbin:/sbin:/usr/sbin:/opt/php53/bin:/opt/php53/sbin
env[TMP] = /tmp
env[TMPDIR] = /tmp
env[TEMP] = /tmp

As always, YMMV.

Categories: PHP, PHP-FPM
  1. Mikael Fridh
    August 26th, 2010 at 07:42 | #1

    I'm not yet a php-fpm convertee but to me
    I'd already be using the fpm.d folder for including global settings in a glob in php-fpm.con so I'd move fpm.d/common.conf /opt/php53/etc/pool-common.conf to move it away from any .d folder.

    Otherwise, nice solution. Has a Debian feel to it.

  2. mike
    August 26th, 2010 at 12:42 | #2

    I had thought about that. I guess it depends on the results coming back from my query to the mailing list about global inheritance.

    I'll probably revise it to make it a bit shorter, no fpm.d/sites dir.

  3. Ben
    September 29th, 2010 at 06:45 | #3


    Is there a complete documentation about all configuration parameters in php-fpm with an explanation about what it means/does?

    Thanks for a link.

  4. Amar
    October 9th, 2010 at 11:42 | #4

    How would you include php_defines in your pools above ? What I want is per pool specific php.ini directives so for ex. for pool amar I would want
    open_basedir = /home/amar/web


  5. mike
    October 9th, 2010 at 14:29 | #5

    Should be as simple as this:

    listen =
    user = mike
    group = mike
    request_slowlog_timeout = 5s
    slowlog = /opt/php53/var/log/slowlog-mike.log
    pm.max_children = 5
    pm.start_servers = 3
    pm.min_spare_servers = 2
    pm.max_spare_servers = 4
    pm.max_requests = 500
    php_admin_value[sendmail_path] = /usr/sbin/sendmail -t -i -f www@my.domain.com
    php_flag[display_errors] = off
    php_admin_value[error_log] = /var/log/fpm-php.www.log
    php_admin_flag[log_errors] = on
    php_admin_value[memory_limit] = 32M
    include = /opt/php53/etc/fpm.d/common.conf

    The example directives come from http://www.php.net/manual/en/install.fpm.configuration.php

  6. Amar
    October 11th, 2010 at 13:01 | #6

    Tnx mike, that worked well

    Have you played with fpm and chroot maybe ?

  7. mike
    October 11th, 2010 at 13:45 | #7

    Nope, haven't used chroot. Haven't had a need, honestly. I run a pretty tight ship with per-user FastCGI pools already, so assuming people don't have world-writable permissions, people's files are as secure as normal shell access should allow. Which isn't as "locked down" as it should be, but it's fine with me for now.

  8. Guix
    November 10th, 2010 at 00:20 | #8

    Hello Mike,
    I'm veeeeery interested by those posts about PHP-FPM and nginx. I'm having some difficulties on my quadcore (i5 750) server with 4GB of RAM. PHP-FPM processes are using quite a lot of CPU therefore overloading the server. I use 5 static processes and don't really know if I should switch to "dynamic". When I do so, there are more php-fpm processes using less CPU, but overall the CPU usage is the same ... and too high. Do you have any idea about something I could tweak in my setup?
    I use PHP5.3.3 + php-fpm + nginx + xcache
    All that for a wordpress site with the W3 Total Cache plugin.

    Any help greatly appreciated :)

  9. mike
    November 10th, 2010 at 00:28 | #9

    Well, I would recommend posting to the PHP-FPM mailing list (highload-php-en) and pastebin your configuration. Include your OS / version / kernel version. It could just be that the code really is inefficient and using a lot of CPU; or it could be deeper problem.

    Sadly I haven't had a lot of experience with PHP-FPM in 5.3.x yet - I can only run it at home right now, and it has not much load on it at all :)

    Typically if you use static processes, I would say to define the number of processes to be the number of concurrent PHP requests you are serving roughly at peak time. Otherwise, the upstream (nginx) will be blocking and waiting for an engine to open up, which could eventually lead to a 504 if it's waiting too long.

    That won't really help your CPU problem out, as you said it seems to use the same amount of CPU overall... but it might help with responsiveness if you wind up with any issues there. 5 is not a very high number at all :)

  1. No trackbacks yet.