Resources
PHP-FPM Status Page Setup Guide
Contents
1. Update PHP-FPM Config
Locate the configuration file for your www pool. Usually it’s located at /etc/php-fpm.d/www.conf.
Enable the pm.status_path parameter by setting it to /php-fpm/status.
pm.status_path=/php-fpm/status
Valid PHP-FPM Config
php-fpm -t
2. Update Web Server
NGINX
location /php-fpm/status {
fastcgi_pass unix:/var/run/php-fpm/php-fpm.sock;
fastcgi_index /php-fpm/status;
fastcgi_param SCRIPT_FILENAME $realpath_root$fastcgi_script_name;
include fastcgi_params;
}
nginx -t
Apache
ProxyPass "unix:/var/run/php-fpm.sock|fcgi://127.0.0.1/php-fpm/status"
httpd -t
3. Securing the Status Page
NGINX
location /php-fpm/status {
allow 127.0.0.1; # restrict to localhost
allow 10.0.0.0/8; # restrict to internal ips
deny all; # don't allow anyone else
# ... your standard fastcgi params
}
nginx -t
nginx -s reload
Apache
Order Allow,Deny
Allow from 127.0.0.1 10.0.0.0/8
# ... your standard fastcgi params
httpd -t
service httpd restart
4. View Status Output
Open http://127.0.0.1/php-fpm/status?full to view PHP-FPM’s complete status page. You can also get a condensed page at http://127.0.0.1/php-fpm/status, or in json format at http://127.0.0.1/php-fpm/status?json.
The status page shows manager level statistics and per-process stats. Depending on what you’re trying to debug, different sections may be helpful.
Here’s what my status page looks like:
pool: www
process manager: dynamic
start time: 17/Apr/2023:16:31:51 +0000
start since: 203
accepted conn: 16
listen queue: 0
max listen queue: 0
listen queue len: 0
idle processes: 5
active processes: 1
total processes: 6
max active processes: 2
max children reached: 0
slow requests: 0
************************
pid: 12493
state: Idle
start time: 17/Apr/2023:16:31:51 +0000
start since: 203
requests: 3
request duration: 148003
request method: POST
request URI: /wp-cron.php?doing_wp_cron=0000000.0000000000000000
content length: 0
user: -
script: /opt/marketing/wordpress/wp-cron.php
last request cpu: 67.57
last request memory: 6291456
************************
pid: 12494
state: Idle
start time: 17/Apr/2023:16:31:51 +0000
start since: 203
requests: 3
request duration: 219
request method: GET
request URI: /status2?all
content length: 0
user: -
script: /opt/marketing/wordpress/status2
last request cpu: 0.00
last request memory: 2097152
(repeating for each PID)
Status Page Output Definitions
Here is an explanation of the metrics shown on the status page. Most are self explanatory, but here’s the nitty gritty details.
Pool Details
- pool: The name of the pool (usually www)
- process manager: The type of process manager used for this pool (see your php-fpm/www.conf)
- start time: The timestamp when the pool was started
- start since: The number of seconds that the pool has been active
- accepted conn: The number of connections the pool has accepted
- listen queue: The number of requests that are currently waiting for a free process
- max listen queue: The max number of requests in the listen queue since the pool was started
- listen queue len: The max number of requests that will be queued before requests will be rejected
- idle processes: The number of processes that are alive, but not processing anything
- active processes: The number of processes that are currently processing a request
- total processes: The total number of processes in the pool
- max active processes: The max number of processes that the pool will spin up to service the request load
- max children reached: A boolean (0 or 1) that shows 1 if the max active processes has been reached
- slow requests: A counter of requests that took >= request_slowlog_timeout (see php-fpm/www.conf)
Process Details
- pid: The system pid for that process. This can be useful for tracing or killing a specific process.
- state: Wether the process is idle or running
- start time: The timestamp when the process was started
- start since: The number of seconds that the process has been active
- requests: The total number of requests served
- request duration: The time (in seconds) that has been spent processing the last request. If you have a large value here, you may want to check your server load or optimize your code.
- request method: The HTTP method of the last request processed
- request uri: The URI of the last request processed (The URI passed to php-fpm. This may not match the user requested URI because of your nginx or apache configuration)
- content length: The body length of the last request processed
- user: The PHP_AUTH_USER of the last request processed
- script: The absolute path of the script executed by the last request. This is very useful when tracking down what script is actually running.
- last request cpu: The % of cpu required to process the last request. This only has a value if the process state is idle. Large values here may point to slow/bloated website code.
- last request memory: The max amount of memory that the last request used. Large values here may point to too many objects or unnecessary data loading.
Monitoring Integrations
Integrations allow you to track metrics from the PHP-FPM status page and create warning alerts. If you have a status page that you don’t look at, it’s not that useful. But, piping the data into a 3rd party can make it very useful for you and your team.
Here are some guides on how to integrate your PHP-FPM status page into specific providers.
ElasticSearch Integration
- module: openmetrics
metricsets: ['collector']
period: 10s
hosts: ["127.0.0.1:80"]
metrics_path: /php-fpm/status
DataDog Integration
instances:
- openmetrics_endpoint: http://127.0.0.1/php-fpm/status
namespace: php-fpm
metrics:
- .+:
type: gauge
service datadog-agent start
Your data should start appearing in your dashboard within a few minutes.
Read more in the Datadog Openmentrics Documentation
Common Status Properties to Watch
Your PHP-FPM status page has some valuable insights on the performance of your application. Here are a few key insights we’ve used to improve our performance.
- Check your slow requests counter. If you start seeing >= 5 requests per day, you may need to check your app code. You can dig into your http log (e.g. /var/log/nginx/access.log) to narrow down exactly which request is causing the problem.
- Check your max listen queue counter. You want to see seeing numbers lower than the number of processes in your pool. Anything over that and you’re going to start seeing very overall slow response time and a laggy site.
- Check specific process last request memory. It’s normal for requests to use a chunk of memory. But a request that uses more than a few MB probably needs some attention. Often large requests can be moved to background jobs or refactored in the application.
If you watch these properties, you’ll be able to narrow down most performance issues. Your site will be snappier and your customers will be happier.