Websites on PHP-FPM are unavailable or loading slowly: server reached max_children setting (*), consider raising it

Symptoms

• Websites that have PHP handler set as FPM application served by Apache or FPM application served by nginx at Domains > example.com > PHP Settings experience one of the following issues:
  • the site is loading slowly
  • there is a high load on server resources (CPU / RAM / DISK)

  • not accessible (permanently or periodically) with a 50x error in a web-browser:

    PLESK_INFO: 502 Bad Gateway

    PLESK_INFO: 503 Service Temporarily Unavailable

    PLESK_INFO: 504 Gateway Time-out

    Cloudflare 522 timeout error

• The following message appears in the PHP-FPM error logfile /var/log/plesk-phpXX-fpm/error.log (where XX is a PHP version used by the websites):

  CONFIG_TEXT: WARNING: [pool example.com] server reached max_children setting (*), consider raising it

  • The message above is usually accompanied with this error:

    CONFIG_TEXT: unable to read what child say: Bad file descriptor (9)

• If nginx is enabled on the server, one of the following error messages may appear in domain's error logfile /var/www/vhosts/system/example.com/logs/proxy_error_log:

  CONFIG_TEXT: [error] 11456#0: *118348 connect() to unix:///var/www/vhosts/system/example.com/php-fpm.sock failed (11: Resource temporarily unavailable) while connecting to upstream, client: 203.0.113.2, server: example.com, request: "GET / HTTP/1.1", upstream: "fastcgi://unix:///var/www/vhosts/system/example.com/php-fpm.sock:", host: "example.com"

  CONFIG_TEXT: [error] 20058#0: *4725139 upstream prematurely closed connection while reading response header from upstream, client: 203.0.113.2, server: example.com, request: "POST /path/to/some/file HTTP/2.0", upstream:

• Requests are being served slowly or not served at all, and therefore, the websites become inaccessible, even though the server's CPU and RAM resources are not exhausted.

Cause

The server receives a large number of requests, which leads to the PHP-FPM pm.max_children limit being reached by the website(s). This usually indicates that the server is under attack or that the number of website(s) visitors has increased sharply. Attacks or increased visitor traffic put a strain on the server's CPU, as PHP handlers that execute code begin to use the CPU more actively to process incoming requests.
 

Resolution

1. Ensure the server isn't under attack. You can use this article to do this:
   How to diagnose a DoS/DDoS attack and find websites under attack on a Plesk server
2. If an attack has been detected, it is necessary to take measures to protect the server from attacks as described in this article: What DDoS protection tools are available in Plesk
   If no attacks are detected, proceed to the next step.
3. You need to monitor the server using this article: How to monitor usage of system resources in a period of time using atop
   - If the CPU and memory load are not high <60%, you can increase the parameter pm.max_children to handle more requests. You have a reserve of resources up to 80% load.
   To calculate the pm.max_children Use this article: How to calculate pm.max_children value on a Plesk server?.
   - If the server's processor or memory is loaded at 80% or more, it's necessary to increase the number of processor cores or the amount of RAM on the server, depending on which resource is overloaded.
   Once the server resources have been expanded, you can begin to increase the parameter pm.max_children so that the server can handle more requests. To calculate the pm.max_children use this article: How to calculate pm.max_children value on a Plesk server?

Note: Increasing the limit pm.max_children should only be done after a full investigation of the server using the articles provided above.

This is a complex administrative task that involves planning and optimizing server resources and settings. Slow code execution often also leads to timeout errors, so additional code review and optimization by developers is a good solution.