Two process management methods and optimizations of php-fpm used by Nginx

php-fpm currently has two main branches, corresponding to versions php-5.2.x and php-5.3.x respectively. In version 5.2.x, php-fpm.conf uses the XML format, while in the newer version 5.3.x, it uses the same configuration style as php.ini.

There are two styles for process management—static and dynamic. The process management is actually the same as in previous versions, except that it's changed from apache-like to dynamic, which makes it easier to understand.

If set to static, the number of php-fpm processes will always be the number specified by pm.max_children, and will not increase or decrease.

If set to dynamic, the number of php-fpm processes is dynamic. It starts with the number specified by pm.start_servers. If there are many requests, it will automatically increase to ensure that the number of idle processes is not less than pm.min_spare_servers. If the number of processes is too large, it will also perform corresponding cleanup to ensure that the number of excess processes does not exceed pm.max_spare_servers.

These two different process management methods can be adjusted according to the actual needs of the server.

Let me first explain a few parameters involved in this; they are:pm、pm.max_children、pm.start_servers、pm.min_spare_servers和pm.max_spare_servers。

pm indicates which method to useThere are two values to choose from, namelystatic(Static) ordynamic(Dynamic). In older versions, dynamic was called apache-like. You should refer to the configuration file for details.

The following four parameters mean the following:

pm.max_children: The number of php-fpm processes started in static mode.
pm.start_servers: The number of php-fpm processes started in dynamic mode.
pm.min_spare_servers: The minimum number of php-fpm processes in dynamic mode.
pm.max_spare_servers: The maximum number of php-fpm processes in dynamic mode.

If `dm` is set to `static`, then only the `pm.max_children` parameter takes effect. The system will start the specified number of php-fpm processes.

If `dm` is set to `dynamic`, the `pm.max_children` parameter becomes ineffective, and the last three parameters take effect. The system will start `pm.start_servers` php-fpm processes when php-fpm begins running, and then dynamically adjust the number of php-fpm processes between `pm.min_spare_servers` and `pm.max_spare_servers` according to system needs.

So, which execution method is better for our server? In fact, like Apache, PHP programs will inevitably experience memory leaks to some extent after execution. This is why a php-fpm process initially uses only about 3MB of memory, but after running for a while, it will rise to 20-30MB.

For servers with ample memory (e.g., 8GB or more), specifying a static `max_children` is more appropriate, as it eliminates the need for additional process count control, improving efficiency. Since frequently starting and stopping the php-fpm process can cause latency, enabling static processes yields better results when memory is sufficient. The number can also be calculated as memory/30MB; for example, with 8GB of memory, setting it to 100 would limit php-fpm memory consumption to around 2-3GB. If memory is slightly less, such as 1GB, specifying a static process count is more beneficial for server stability. This ensures that php-fpm only uses the necessary memory, allocating the remaining memory to other applications, resulting in smoother system operation.

For servers with limited memory, such as a VPS with 256MB of memory, even assuming each process consumes 20MB, 10 php-cgi processes would consume 200MB of memory, making system crashes quite likely. Therefore, the number of php-fpm processes should be carefully controlled. After roughly determining the memory usage of other applications, assigning a static, small number will improve system stability. Alternatively, a dynamic approach can be used, as it terminates unnecessary processes, freeing up memory. This is recommended for servers or VPSs with limited memory. The maximum number can be calculated by dividing memory by 20MB. For example, for a 512MB VPS, setting `pm.max_spare_servers` to 20 is suggested. As for `pm.min_spare_servers`, it's recommended to set it based on the server's load, with a suitable value between 5 and 10.

pm.max_requests = 5000
// The number of requests served before each child process is reborn. The main purpose is to control memory overflow during request processing, keeping memory usage within an acceptable range. Setting it to '0' means continuously accepting requests. It cannot be set to a very small value. When this number is very small, since PHP requests are evenly distributed among worker processes, if this value is too small, all worker processes will reach this value almost simultaneously and enter a restart state. When all worker processes restart at the same time, PHP will stop responding for several seconds or even longer until all processes have restarted. During this time, new requests cannot be processed normally and must wait in the queue until the process restarts completely. If the timeout period is exceeded, a 502 bad gateway error will be displayed. Simultaneously, due to frequent process stopping and creation, CPU utilization will increase significantly. Therefore, this value needs to be adjusted to a slightly larger value. This value can be estimated using the following methods:
pm.max_requests = process restart interval * concurrency / pm.max_children
For example:
All child processes restart every 300 seconds, with a concurrency of 50 and max_children set to 25. max_requests = 300*50/25=600. If you want the process to respawn every hour, then it would be 3600*50/25=7200.

View process:

ps -ylC php-fpm --sort:rss