Php – Relation between PHP-FPM settings and mpm_worker (Apache)

apache-2.2apache-2.4mpm-workerPHPphp-fpm

I've a site running Magento on the following setup:

Apache 2.4 with mpm_worker
PHP-FPM
Total RAM in server: 14GB (10GB avilable to Apache/PHP)

Each PHP-FPM process consumes approximately 80MB of RAM.

I want to fine tune the settings for PHP-FPM and mpm_worker.
Reading in the documentation I'm a bit confused about the relation between options in PHP-FPM and mpm_worker.

E.g., PHP-FPM has configurations: pm.min_spare_servers, pm.max_spare_servers, pm.start_servers and max_children. I understand what these options mean with respect to PHP-FPM.

However, mpm_worker has the following configurations: MinSpareThreads, MaxSpareThreads, StartServers and ThreadLimit. Again, isolated to mpm_worker I understand what they do.

My question is: How does these configurations relate to each other? Let's say I set StartServers=2 and ThreadsPerChild=25. This would give me 50 threads to begin with with respect to Apache/mpm_worker. If I then set pm.start_servers = 50, PHP-FPM will spawn 50 processes initially.

So what is the relationship between these 50 "Apache" threads and 50 "PHP-FPM" processes? Does each Apache thread utilize one PHP-FPM process?

I hope someone can give some insight into this.

Thanks!

Best Answer

Apache serves the requests from the clients using the threads' childs, but it'll only call PHP-FPM for php files - images, css and js should be served directly from Apache, and thus not consume a PHP-FPM thread.

PHP-FPM has multiple threads with no childs - each thread serves a request from Apache.

AFAIK, multiple requests from the same client (loading the page, plus images, css and js) should consume multiple threads if you don't have KeepAlive set in Apache. See this link for more info on KeepAlive.

I've been tuning an Apache server myself recently and found out that if you have multiple cores it's better to increase the number of childs per thread.

Related Solutions

NGINX/PHP-FPM cpu spikes and runaway processes

Well, kinda well. Lots of CPU used but theres only a few of them, so its kinda ok

The amount of work a process does is given by the amount of CPU it uses - hence it's the % usage x the time it's being used for. So if your PHP processes are using up lots of CPU then that's usually a good thing - it means it's not waiting for other stuff to happen. From a systems admin point of view you can make more CPU available for other tasks - but you'll increase the amount of time taken for a PHP process to handle a request.

And of course if requests are coming in at steady rate, taking longer to process them means that there will be more process working (or waiting to be scheduled) at any one time, and the larger memory footprint means less memory available for VFS caching. There's also the risk that the scheduler will start pre-empting tasks rather than letting them yeild which decreases overall throughput.

Hence you should be aiming for high CPU usage! (but low load).

Memory limit in php.ini is 128mb

This is rather high, but since the CPU usage is high that indicates it's not too much of a problem UNLESS each request is taking a long time to complete and doing a lot of garbage collection - in this scenario, forcing more frequent garbage collection by reducing the memory limit can actually improve performance.

I've had so much downtime lately

For what it's worth I've found APC to be a lot more reliable than Xcache - and that seems to be the trend in what I've read elsewhere. Don't have any experience / data on the Zend Optimizer+ which is due to be bundled with future versions of PHP.

I'm verging on setting up Apache again and I'd love to stick with this

Pre-fork apache + mod_php is significantly faster than nginx + php-fpm at lower traffic volumes - but nginx seems to have a massive advantage when the load / request rate is medium - high relative to the hardware capacity (which is where you seem to be).

If it were me I'd be looking hard at the logs to see if the spikes are due to an increase in the traffic volume / a change in the traffic profile / a change in the response time. Also looking hard at caching and code. You might consider temporarily running a profiler against the live site (use xhprof - not xdebug for a production system).

Apache Scoreboard Full – Meaning of “AH00485: Scoreboard is Full, Not at MaxRequestWorkers”

We had the same problem on Apache 2.4.6. After monitoring the server and adjusting the setting for several hours it appears to us that Apache may have a bug. What appears to happen is that the server processes occasionally goes into the G state (Gracefully finishing) and restarts to accept new requests, that's normal. What is not normal is that for some reason this can take up to a few minutes to restart. If you only have a few server process running and they all go into the G state at the same time then your scoreboard fills up and you won't be able to server any more requests.

What we did was increase the number of servers so there is a less of a chance that they will all go into the G state at the same time. Also make sure you allocate at least 25 threads (MaxRequestWorkers) for each server process because that appears to be the default (i.e. if 5 Servers x 25 ThreadsPerChild = 125 MaxRequestWorkers). You can change ThreadsPerChild if you like, we left it at default. If you don't allocate enough threads the additional servers will not start. We left MinSpareThreads at the default value which is 25 and the default for MaxSpareThreads which is 75. If you do modify these settings, the value for MaxSpareThreads must be greater than or equal to the sum of MinSpareThreads and ThreadsPerChild. Also MaxRequestWorkers must be equal to or less than the ServerLimit.

Here is what worked for us but it might not be the best configuration for you.

StartServers 3
MinSpareServers 5
MaxSpareServers 10
ServerLimit 250
MaxRequestWorkers 250
MaxConnectionsPerChild 1000
KeepAlive Off

Edit: This is a confirmed bug in httpd's mpm_event module which might not be fixable through configuration.
The linked bugtracker entry has a presumed patch and more discussion about how to fix this until a new version of the event module is officially released.

Best Answer

Related Solutions

NGINX/PHP-FPM cpu spikes and runaway processes

Apache Scoreboard Full – Meaning of “AH00485: Scoreboard is Full, Not at MaxRequestWorkers”

Related Topic