Occasionally, you may run into a max_children error with the PHP-FPM server:

[10-Dec-2018 04:30:31] WARNING: [pool example1] server reached max_children setting (5), consider raising it 

This can be fixed by typically making a change to the php-fpm.conf file, but you should also check for the other possible causes of that error. As PHP-FPM is a part of the UltraStack configuration, you will normally only see this error with that configuration in place (unless you have configured your server to use PHP-FPM). This article discusses the typical causes of this error and how to change the value within the configuration file.

• Causes of the Error
• Find your CENTOS Version
• Fix the Max_Children Error
  • CENTOS 6.x Instructions
  • CENTOS 7.x Instructions

Looking for a new home for your WordPress website? Look no further than InMotion Hosting’s WordPress Hosting solutions for secure, optimized servers that meet your budget needs.

Causes of the error

There can be a number of reasons that this error will occur. You should always check your server’s performance and resource usage to help prevent errors. The typical causes of this error include:

• High traffic (concurrent visitors)
• Bad scripts or code that leads to slow execution of PHP code
• Low settings for the max_children setting in the PHP-FPM Config

As resource usage may often be the cause of this problem, make sure that your server has been properly optimized and tuned. A good guide for this topic is the WordPress Stack Optimization Guide: Tuning for VPS & Dedicated Servers.

Find Your CENTOS Version

Before you fix the value causing the error, you will need to first determine what version of CENTOS that you are running. This will help us give you the steps matching the interface that you’re seeing.

Look in the top right corner of WHM (where you should be logged in as ROOT).

Your version should be either 6.x or 7.x of CENTOS. Use the corresponding directions below to fix the error.

Fix Max_Children Error by Increasing the Value

In order to make changes to the configuration for PHP-FPM you will need to have at least a VPS subscription. This will allow you to access the Web Host Manager (WHM) which is used in this solution. You will also need a ROOT user login. Shared server resellers will need to submit a support ticket for changes to the configuration.

CENTOS 6x Instructions

1. Login to WHM as Root.
2. In the search field in the top left corner, type in MultiPHP Manager.
3. You will see the option for MultiPHP Manager under Software. Click on it to proceed.
4. Click on the System PHP-FPM Configuration tab.
5. Increase Max children as needed. It starts at 5 by default.
6. When you have completed adjusting the value for Max Children, make sure to scroll to the bottom of the screen and click on Save Configuration.

CENTOS 7.x Instructions

1. Log in to WHM as Root.‘
2. In the search field in the top left corner, type in MultiPHP Manager.
3. You will see the option for MultiPHP Manager under Software. Click on the icon or menu item to proceed.
4. You will be on the MultiPHP Manager page. Make sure that PHP-FPM is enabled and then click on the Manage Settings button to the right.
   
5. You will then be on the System Settings tab, and you will see a title of System PHP-FPM Settings. Look for the Max children setting, then click on the number area where you will typically see a value of 5.
   
   
6. Increase the value of the Max Children as needed.
7. Once you have the value of Max Children set as needed, scroll to the bottom of the page and click on Update.

You can also find articles and guides on PHP-FPM in the InMotion Hosting Support website!

If you are unsure of the proper value, contact our live technical support team or submit a support ticket. For more information, see our other UltraStack tutorials.

1. Login WHM as Root.
2. From the menu, search and select MulitiPHPManager.

3. 

   Select Turn on to enable PHP-FPM for all cPanel accounts. Alternatively, you can select the checkbox beside specific domains at the bottom, choose On from the dropdown menu beside PHP-FPM, and select Apply.
   You can also change the PHP version here instead of in cPanel.

4. Select Pool Options beside the specified domain.

5. 

   Modify PHP-FPM settings for the domain. Below are commonly successful changes according to amount of traffic your VPS receives.

   Traffic Load	Average	Heavy
   Max Children	25-35	40-60
   Process Idle Timeout	100	100-150
   Max Requests	200-350	400-600

Edit Default PHP-FPM Settings

If you have many cPanel accounts, you may prefer to change the default settings for newly created cPanel accounts.

1. As root, SSH into your server or launch WHM terminal.
2. Create a system_pool_defaults.yaml file in the /var/cpanel/ApachePHPFPM directory. To do this using nano, type the following:
   nano /var/cpanel/ApachePHPFPM/system_pool_defaults.yamlAdd the following to the new file:php_value_error_reporting: 'E_ALL'
pm_max_children: 500
pm_max_requests: 2000
pm_min_spare_servers: 1
pm_max_spare_servers: 25
pm_process_idle_timeout: 150
php_value_disable_functions: 0
   pm_max_children: Max number of child processes
   pm_max_requests: Number of requests a child process executes before respawning.
   pm_min_spare_servers: Minimum idle server processes
   pm_max_spare_servers: Maximum idle server processes
   pm_process_idle_timeout: Time until an idle process is killed in s(econds), m(inutes), m(inutes), h(ours), or d(ays).
   php_value_disable_functions: Functions to disable. This doesn’t overwrite php.ini settings.
3. Save and exit the file. Using nano, press Control and x for the save prompt before exiting. Press y, then Enter ⤶ to save the file.
4. Rebuild PHP-FPM using the following command:
   /scripts/php_fpm_config --rebuild
5. Restart PHP-FPM using the following command:
   /scripts/restartsrv_apache_php_fpm

   Note:You can also restart PHP-FPM from WHM.

These adjustments should help you make the most out of your VPS optimization and PHP hosting. You can learn more configuration options for PHP-FPM with official cPanel documentation. You can read more about the benefits of PHP-FPM in our in-depth article.

WHM

1. Log into WHM as root.
2. Search “PHP-FPM” and select PHP-FPM service for Apache.
   
3. Select Yes to restart the PHP-FPM service.
   
4. Check the updated website.

SSH

1. Ensure you have root access enabled in AMP.
2. SSH into your server as root.
3. Type the command

   /scripts/restartsrv_apache_php_fpm

   to restart PHP-FPM. The results should mirror below:
   
4. Check the updated website.

You should be able to see the updated website after clearing your browser cache or using a private window. If installed, you may also want to clear the Nginx cache using cPanel Cache Manager or SSH command

service nginx restart

or

systemctl restart nginx

You can read more detailed information in our in-depth PHP-FPM article and comparison between it and SuPHP.

Long the PHP handler of choice, suPHP securely runs PHP websites like WordPress using the Apache web server. However, PHP-FPM is rapidly replacing suPHP as the most popular PHP handler thanks to its improved security, performance, and stability. InMotion Hosting’s WordPress Hosting platform uses PHP-FPM to provide excellent PHP performance for WordPress.

Why use suPHP?

suPHP provides modules used by the Apache web server to dynamically change the user ID of the running Apache web server process over to the owner of a requested PHP script. By default, an Apache web server running WordPress (and/or other PHP web applications) processes PHP scripts itself. This means PHP scripts run using the same permissions and level of access that the Apache web server’s own processes have. When properly configured, an Apache web server’s processes usually run as their own special user. This prevents scripts that the web server runs from accessing restricted folders and files. However, in environments with multiple websites or multiple users on the same server (as in a shared hosting environment), executing PHP scripts as the Apache web server’s user allows PHP scripts to access every user’s or website’s files and folders. suPHP prevents this by restricting PHP scripts, only allowing them to access the files and directories that the scripts’ owners can access. suPHP’s security enhancements provided a huge leap forward for PHP handling using the Apache web server. Without suPHP, shared hosting platforms would have been extremely difficult to secure. Those platforms rely on suPHP to maintain discrete, isolated user spaces for multiple users on the same server.

Fortunately, suPHP is also extremely easy to configure on virtual private servers (VPS) and dedicated servers, especially when using popular server management tools like cPanel. However, users typically require root access to install suPHP. cPanel, for example, makes installing suPHP very simple using its EasyApache 4 configuration tool. suPHP can require much less configuration and maintenance than PHP-FPM due to its simple functionality.

Why use PHP-FPM?

While suPHP provides many benefits and represented a huge leap forward in security for shared hosting environments, PHP-FPM has risen to take its place in many ways. PHP-FPM not only provides better security than suPHP, but it also processes PHP scripts much more efficiently than suPHP. When configured properly, PHP-FPM provides completely isolated pools of memory and processes for each user and website for handling PHP scripts as that script’s owner. On the other hand, PHP scripts processed using suPHP start execution as the Apache web server’s user and only change to the PHP script’s owner part way through execution. The system still executes PHP scripts as part of the Apache web server process even though suPHP changes the process’s user ID while running the requested PHP script.

Event-driven Architecture

PHP-FPM can also achieve much higher performance than suPHP due to its event-driven architecture. When using PHP-FPM, PHP processing completes outside of the web server’s processes. Each request for a PHP script gets sent to a dedicated PHP-FPM service for processing. Using a separate service allows PHP processing to use only as many server resources as required. PHP-FPM’s independence from the web server also enables fine tuning of PHP-FPM to provide the best performance for WordPress and other PHP applications.

Opcode Caching

More importantly, the isolated user memory pools PHP-FPM uses makes opcode caching possible. PHP-FPM can use opcode caching to save a compiled copy of each PHP script into the user’s memory pool. When PHP-FPM receives a request for a cached script it can use the cached copy of the PHP script to skip reading and compiling before executing the PHP script. Even if a user enables opcode caching on suPHP, each PHP script processes in complete isolation and cannot access a shared pool of memory for storing compiled copies of PHP scripts. Opcode caching provides the key factor for PHP-FPM, enabling it to provide high performance PHP processing. Websites run using PHP-FPM and opcode caching can serve more visitors more quickly than websites using suPHP.

Why InMotion Hosting Recommends PHP-FPM

Notably, the original suPHP project no longer receives updates or further development. suPHP does not even receive patches for any security vulnerabilities that researchers may discover. This does not necessarily mean that websites or servers using suPHP are currently vulnerable; however, for long-term security, users should replace suPHP with another PHP handler such as PHP-FPM. Quickly becoming the desired PHP handler for PHP, PHP-FPM will continue to receive development and support for years to come as suPHP gradually phases out of use.

Although PHP-FPM can be more difficult to configure than suPHP, cPanel and other server management tools have started providing pre-built configurations and packages for easily installing it on virtual private servers and dedicated servers. Even with these tools, however, PHP-FPM utilizes a more complex and advanced technology that can require more planning and work in order to get the most out of it. InMotion Hosting suggests working with a server administrator experienced in using PHP-FPM.

InMotion Hosting’s WordPress Hosting platform provides PHP-FPM installed and pre-configured by web hosting experts to provide a secure, high-performance environment for WordPress websites.

PHP-FPM is an improved PHP handler that uses a pool of workers (per domain) to quickly process PHP scripts. Once the script completes running, PHP-FPM provides the results to Apache to deliver to the visitor’s browser.

In this guide, you will learn the steps needed to enable PHP-FPM through Web Host Manager (WHM).

1. 1. 

      Log into WHM, as the root user.
   2. 

      In the WHM search bar, type “php“.
   3. 

      Click the MultiPHP Manager menu option.

1. 1. 

      Under the section labeled Set PHP Version per Domain find the domain you want to enable PHP-FPM for and click the checkbox to the left of it. Then, select On from the PHP-FPM drop-down menu and click the Apply button.

A notification will briefly appear indicating that PHP-FPM settings have been applied to the selected domain(s).

Congratulations! Now you know how to enable PHP-FPM for your cPanel users’ websites.

For an overview of InMotion Hosting’s WordPress Hosting platform and how PHP-FPM fits into it, please refer to our guide discussing the technologies used in the WordPress Hosting Stack.

• PHP-FPM’s Architecture
• Performance
• Security
• Stability
• Configurability

PHP-FPM’s Architecture

As a high-level programming language, PHP scripts require compiling before a web server’s underlying processor hardware can understand it. Traditionally, the web server handles compiling PHP scripts through integrated web server modules such as single user PHP (suPHP), Common Gateway Interface (CGI), or Dynamic Shared Object (DSO, also known as mod_php). When using these PHP handlers, the web server tightly couples to processing PHP scripts. The server compiles and executes the PHP scripts as part of the individual web server’s processes as it responds to website traffic. They execute using the web server processes’ permissions and ownership configurations. Running PHP this way provides a stable, mature means of using PHP scripts. However, PHP-FPM provides a new experience that addresses many of the shortcomings of the previously mentioned PHP handlers (suPHP, CGI, and DSO).

When using PHP-FPM, a separate service specifically designed for processing PHP scripts handles the task. Internally, PHP-FPM is organized as a “master process” managing pools of individual “worker processes.” When the web server has a request for a PHP script, the web server uses a proxy, FastCGI connection to forward the request to the PHP-FPM service. The PHP-FPM service can listen for these requests on the host server’s network ports or through Unix sockets. Although requests pass via a proxy connection, the PHP-FPM service must run on the same server as the web server. Notably, the proxy connection for PHP-FPM is not the same as a traditional proxy connection. As PHP-FPM receives a proxied connection, a free PHP-FPM worker accepts the web server’s request. PHP-FPM then compiles and executes the PHP script, sending the output back to the web server. Once a PHP-FPM worker finishes handling a request, the system releases the worker and waits for new requests.

The PHP-FPM master process dynamically creates and terminates worker processes — within configurable limits — as traffic to PHP scripts increases and decreases. The extra worker processes it spawns to handle increases in traffic terminate only after a set amount of time has passed, allowing the worker processes to remain available while increased traffic persists. Worker processes also periodically terminate and respawn after serving a fixed number of requests. This helps to prevent memory leaks during the processing of PHP scripts. Each PHP user can have its own separate pool of worker processes for handling PHP requests. Although this does increase some of the overhead of using PHP-FPM, the additional resource cost is negligible and well-offset by its other benefits.

PHP-FPM’s architecture shares design similarities with event-driven web servers such as the NGINX web server and the Apache web server with the Event Multi-Processing Module. Processing PHP scripts in this way allows for much higher processing performance, improved security, better stability, and greater configurability.

Performance

The primary performance benefits of using PHP-FPM are more efficient PHP handling and the ability to use opcode caching for PHP scripts.

As mentioned, PHP-FPM’s event-driven framework allows PHP scripts to use as much of the server’s available resources as necessary without the additional overhead that comes from running them inside of web server processes. PHP-FPM can reuse worker processes repeatedly instead of having to create and terminate them for every single PHP request. Although the cost of starting and terminating a new web server process for each request is relatively small, the overall expense quickly increases as the web server begins to handle increasing amounts of traffic. PHP-FPM can serve more traffic than traditional PHP handlers while creating greater resource efficiency.

The largest performance improvement resulting from using PHP-FPM comes from enabling opcode caching for PHP scripts. When using opcode caching, the resulting opcode from compiled PHP scripts gets cached in memory (RAM). If a request comes in for a PHP script, PHP-FPM quickly checks for previously cached copies of the script. When it finds a cached copy, PHP-FPM executes the script using the cached opcode immediately and continues processing the request.

This ability to immediately execute the opcode from memory removes the need for reading the script’s source code from disk and compiling the PHP source code to opcode. Reading data from the server’s memory is orders of magnitude quicker than reading the same data from the server’s filesystem. PHP-FPM also saves time and resources by not having to compile the PHP source code to opcode. As with starting and terminating processes, the cost and time to read a source code file and compile it may be relatively small on its own but grows with additional instances. For example, when a system repeats those steps tens, hundreds, or even thousands of times a second, the aggregate cost can significantly impact the resource usage of a web server. Using opcode caching significantly improves the efficiency of processing PHP scripts, especially when processing large volumes of requests for PHP scripts.

Security

Enabling opcode caching while still maintaining isolated PHP processing for each user allows PHP-FPM to offer enormous security benefits over other PHP handlers. Opcode caching has no effect when using the suPHP and CGI handlers due to the way these handlers manage their memory usage. The DSO handler supports opcode caching, but the DSO module requires running PHP scripts as the Apache user, which can create a security risk. Using DSO may also require additional configuration to ensure that PHP scripts have the proper permissions to allow the Apache user to read them. There are solutions for this problem, but they usually involve installing additional server modules or relying on outdated technologies. By default, PHP-FPM provides opcode caching and isolated PHP script processing.

When using opcode caching, one must take care to configure PHP-FPM for security. For example, the server’s main PHP configuration file should have the following values set to true:

opcache.validate_root = true 
opcache.validate_permission = true

These settings provide an additional layer of restriction that can prevent users from obtaining access to other users’ opcode caches. The main PHP-FPM configuration files contain the necessary settings for providing secure use of PHP-FPM. These concerns apply primarily to multi-tenant hosting environments. For example, InMotion Hosting’s WordPress Hosting platform provides a multi-tenant hosting environment configured to provide a secure platform with PHP-FPM.

Stability

PHP-FPM’s architecture prevents PHP processing from overwhelming a server. When web servers handle requests for PHP scripts in their own processes, additional web server processes have to be created. As traffic for PHP scripts increases, web servers can quickly become overwhelmed, even to the point where the host server becomes unresponsive.

PHP-FPM can only serve as much traffic as it has worker processes to handle. When properly configured, this creates a relatively hard limit on how many requests for PHP scripts it can process at the same time through PHP-FPM. As PHP-FPM’s worker processes become fully utilized, additional requests for PHP scripts will result in timeouts or gateway errors from PHP-FPM. Instead of using up server resources waiting for a response, the web server will simply return a 503 or 504 HTTP status code. Although site visitors may not want to see 503 or 504 HTTP status codes, this behavior is far better than allowing the hosting server to become entirely unresponsive. Additionally, site owners can create custom 503 status pages to improve the user experience versus a non-descript white error page.

Although PHP-FPM’s architecture provides stability, when improperly configured PHP-FPM can become a bottleneck in processing PHP scripts. Properly configuring PHP-FPM to provide enough workers to process the amount of traffic that the web server can process remains key. Too few workers can result in excessive 503 or 504 HTTP responses, even though the web server is not experiencing high levels of traffic. This problem occurs more frequently with single-tenant servers running PHP-FPM with a single pool of worker processes for all websites, such as a virtual private server or a dedicated server. However, multi-tenant hosting environments with separate pools of worker processes also need to have a properly configured PHP-FPM in order to provide enough workers for each tenant’s web traffic.

Configurability

As a separate service, PHP-FPM provides more configuration options than other PHP handlers. Many of these configuration options can also be defined differently for each website on the server. Some of the options include but are not limited to:

• User for running scripts
• Group for running scripts
• Worker Limits
• PHP-FPM worker creation behavior
• Slow PHP script logging
• Status reports
• Connection settings (e.g. listening on a network port or on Unix socket)
• PHP runtime configuration values

Users can finely tune PHP-FPM to provide superior performance for hosting PHP websites over other PHP handlers lacking such configuration options. Unfortunately, properly configuring PHP-FPM can be relatively complex and involved. Users wishing to do so should consult a skilled systems administrator for configuration assistance should the hosting platform not provide a preconfigured version of PHP-FPM. InMotion Hosting’s own WordPress Hosting platform comes with PHP-FPM preconfigured by systems administration experts to provide the best performance for WordPress users and their visitors while also ensuring a safe and secure hosting environment.