If your website suddenly starts loading very slowly, shows error messages like “503 Service Unavailable” or “504 Gateway Timeout,” or hangs indefinitely, one common culprit could be your PHP-FPM configuration reaching its pm.max_children limit. This guide will help you understand, diagnose, and address this issue on Linux servers using cPanel, Plesk, or InterWorx.

What is PHP-FPM and max_children?

PHP-FPM (FastCGI Process Manager) is an advanced and highly efficient processor for PHP. It manages pools of PHP processes to handle your website’s requests. The pm.max_children setting within PHP-FPM defines the maximum number of simultaneous child processes that can be created within a specific pool to handle incoming PHP requests. Each child process consumes server resources, primarily RAM and CPU.

Symptoms of reaching max_children

When your server hits the pm.max_children limit, it means all available PHP workers are busy. New requests have to wait for an existing worker to become free. This can lead to:

Slow Page Loads: Pages take a very long time to load or don’t load completely.
Site Hanging: Your website becomes unresponsive.
Error Messages: You might see 500, 503, or 504 errors in your browser.
Increased Server Load: While PHP processes might be capped, the queue of waiting requests can still stress the server.

Common reasons for hitting the limit

High Traffic: A sudden surge in legitimate visitors or a DDoS attack can quickly consume all available PHP workers.
Long-Running PHP Scripts: Inefficient code, slow database queries, or calls to external APIs that are slow to respond can cause PHP processes to remain occupied for extended periods.
Insufficient max_children Value: The current setting might be too low for your site’s typical traffic and processing needs.
Server Resource Bottlenecks: Even if max_children is set appropriately, if the server lacks sufficient RAM or CPU power, processes will run slowly, leading to more workers being tied up.

Step 1: Confirming the “max_children” error in logs

Before making any changes, it’s crucial to confirm that reaching pm.max_children is indeed the problem. You’ll typically find explicit error messages in your PHP-FPM logs.

What to look for in the logs

Search for lines similar to this:

WARNING: [pool your_domain_or_user] server reached pm.max_children setting ([current_value]), consider raising it

The location of the logs will vary based on control panel type.

cPanel/WHM log locations

For servers using cPanel with EasyApache’s PHP-FPM:

The main PHP-FPM log for a specific PHP version: /opt/cpanel/ea-php[XX]/root/usr/var/log/php-fpm/error.log (Replace [XX] with the PHP version number, e.g., ea-php74, ea-php81, ea-php83).

Plesk log locations

For servers managed by Plesk:

Domain-specific PHP-FPM logs are often the most relevant: /var/www/vhosts/system/[your_domain.com]/logs/php-fpm_error.log (Replace [your_domain.com] with your actual domain name).
Version-specific PHP-FPM logs: /var/log/plesk-php[XX]-fpm/error.log (Replace [XX] with the PHP version, e.g., php7.4, php8.1).

InterWorx log locations

For servers managed by InterWorx:

If using PHP versions from repositories like Remi, logs might be here: /opt/remi/php[XX]/var/log/php-fpm/error.log (Replace [XX] with the PHP version number, e.g., php74, php81).
User-specific PHP-FPM logs (this can vary based on configuration): /home/[unixuser]/var/php-fpm/logs/error.log /home/[unixuser]/var/[domain.com]/logs/php-fpm.error.log (Replace [unixuser] and [domain.com] accordingly).

Step 2: Check your server’s current resource usage

Before you consider increasing pm.max_children, you must check if your server has enough resources (CPU and RAM) to handle more PHP processes. Increasing this limit on an already overloaded server will make performance worse, not better. If you’re uncertain about this step, our support team is happy to take a look for you.

Why checking resources is crucial

Each PHP-FPM child process consumes memory (RAM) and CPU. If you increase max_children beyond what your server can physically support:

RAM Exhaustion: The server might run out of RAM and start using swap space (virtual memory on disk), which is significantly slower and can cause severe performance degradation or even crashes.
CPU Overload: Too many processes competing for CPU time can lead to everything slowing down.

How to check CPU and memory

Connect to your server via SSH and use these commands:

top or htop: These provide a real-time view of your server’s processes, CPU usage, and memory usage.
- Look at the load average: If it’s consistently higher than the number of CPU cores, your CPU might be a bottleneck.
- Observe the %CPU and %MEM columns for individual processes, especially php-fpm.
free -m: This command shows your total, used, and free RAM in megabytes (MB).
- Pay attention to the free column in the Mem: row and the used column in the Swap: row. High swap usage is a bad sign.

If your server is already using most of its RAM or has a consistently high CPU load, you should focus on optimization (see “Beyond max_children” below) or consider upgrading your server resources before increasing pm.max_children.

Step 3: Adjusting pm.max_children – Proceed with Caution!

If you’ve confirmed the max_children error in logs and your server has available resources, you can cautiously increase the pm.max_children value.

Important considerations before you increase max_children

Make small, incremental changes. For example, increase the value by 10-20% at a time.
Monitor closely after each change to see the impact on performance and resource usage.
One size does not fit all. The optimal max_children value depends heavily on your server’s resources, the nature of your website’s code, and traffic patterns.

Calculating an estimated safe max_children value

A rough way to estimate a starting point for max_children is:

pm.max_children = (Total Available RAM for PHP) / (Average Memory per PHP Process)

Determine Available RAM for PHP:
- Check total server RAM (free -m).
- Subtract RAM used by the OS and other essential services (e.g., MySQL, Apache/Nginx, mail server, cPanel/Plesk itself). This might be 1-2GB or more on larger servers. Let’s say you have 8GB total RAM, and 2GB is for the system, leaving 6GB (6144MB) for PHP and other web applications.
Estimate Average Memory per PHP Process:
- While top or htop is running, observe the RES or RSS (Resident Memory Size) of your php-fpm processes.
- Alternatively, you can try to get an average with a command like (run this when your site is under normal load):
  ps aux | grep 'php-fpm: pool' | awk '{sum+=$6} END {if (NR>0) print sum/NR/1024 " MB"; else print "0 MB"}'
  This command shows the average RSS (Resident Set Size) in MB for active PHP-FPM pool processes. Let’s say this shows an average of 50MB per process.
Calculate:
- Using our example: max_children = 6144 MB / 50 MB = approximately 122.

Caution: This is a theoretical maximum. Always start lower than this calculated value, monitor, and adjust. If your PHP processes are very memory-intensive, your max_children value will need to be lower.

How to adjust pm.max_children in cPanel/WHM

You typically manage PHP-FPM settings per domain or globally via WHM.

Log in to WHM.
Navigate to Software -> MultiPHP Manager.
Go to the User Domains tab.
Find the domain you want to configure and click PHP-FPM Configuration for [domain].
Adjust the Max Children (pm.max_children) value.
Click the Save Configuration button.

cPanel will automatically apply the changes and restart PHP-FPM for the affected pool(s).

How to adjust pm.max_children in Plesk

Plesk allows you to manage PHP-FPM settings on a per-domain basis.

Log in to your Plesk panel.
Go to Websites & Domains (or Domains).
Find the domain you want to configure and click on its name or Hosting Settings.
Click on PHP Settings within the dashboard.
Scroll down to the PHP-FPM Settings section. You should see an option for pm.max_children.
- If these options are not directly visible, your PHP handler might not be FPM, or the options might be controlled by the service plan. Ensure “FPM application served by Apache” or “FPM application served by nginx” is selected as the PHP handler.
Adjust the pm.max_children value.
Scroll to the bottom and click OK or Apply.

Plesk will automatically save the changes and restart PHP-FPM for that domain.

How to adjust pm.max_children in InterWorx

Log in to NodeWorx.
Navigate to SiteWorx > Accounts, then edit the site in question by clicking on the pencil icon under the Action column.
Go to the Package PHP-FPM Settings section.
Look for options to edit PHP-FPM pool configurations and find max_children.
Adjust the value and Save.

InterWorx will handle the necessary PHP-FPM service restart.

Step 4: Monitor your site and server

After making any changes to pm.max_children:

Monitor your PHP-FPM logs to ensure the “max_children reached” warnings have stopped or become less frequent.
Keep an eye on server resource usage (top, htop, free -m) to ensure the server isn’t now struggling with memory or CPU due to the increased limit.
Check your website’s performance and stability.

If issues persist or worsen, revert the change and explore other solutions.

Beyond max_children: Other ways to improve performance

Simply increasing pm.max_children isn’t always the best or only solution. It can be a temporary fix if the underlying cause is inefficient code or insufficient resources. Consider these:

Code and database optimization

Identify Slow Scripts: Use profiling tools (like Xdebug with a profiler, or New Relic APM) to find bottlenecks in your PHP code.
Optimize Database Queries: Slow database queries are a common cause of long-running PHP scripts. Use tools like EXPLAIN in MySQL/MariaDB to analyze and optimize your queries. Ensure your database tables are properly indexed.
Update Web Applications: Keep your CMS (WordPress, Joomla, Drupal, etc.), plugins, and themes updated, as updates often include performance improvements and bug fixes.

Implementing caching

Caching can significantly reduce the number of PHP requests that need to be processed:

Opcode Caching: Usually enabled by default with modern PHP (e.g., OPcache). It stores precompiled script bytecode in shared memory, avoiding the need to recompile scripts on every request.
Object Caching: For database query results or frequently computed data. Tools like Redis or Memcached can be very effective. Many CMS platforms have plugins to integrate these.
Full-Page Caching: Services like Varnish or CDN-based caching can serve static HTML copies of your pages to visitors, bypassing PHP and the database entirely for many requests. CMS caching plugins (e.g., WP Rocket, LiteSpeed Cache) also offer robust page caching.

Considering a server upgrade

If your website has genuinely outgrown your current server’s resources and you’ve optimized as much as possible, it might be time to upgrade to a plan with more RAM, CPU cores, or faster storage.

Conclusion

Troubleshooting PHP-FPM max_children issues involves careful diagnosis, resource assessment, and cautious adjustments. By checking your logs, monitoring server resources, and making informed changes to your PHP-FPM configuration through your control panel, you can often resolve site slowdowns and hangs. Remember that optimizing your website’s code and utilizing caching are key long-term strategies for a fast and stable website. If you continue to experience issues or want a second opinion, our support team is always here to help!

Was this article helpful?

Thank you for your input.

Thank you for your feedback.