If you have purchased a LAMP template or configured a stack, LAMP/LEMP, you are probably using PHP-FPM (an acronym of FastCGI Process Manager): an excellent, more performant alternative to using PHP as an Apache module or PHP FastCGI.
For some years now, we have been using PHP-FPM on all new shared hosting plans and LAMP templates, with excellent results compared to mod_php, an Apache module.
How to optimize RAM consumption of PHP-FPM in Linux environments? To obtain optimal performance and save up to 50% of RAM, one of the possible feasible techniques is the modification of some aspects in the configuration in the PHP-FPM pool.
The default pool is www and is located in /etc/php-fpm.d/www.conf (on CentOS/RHEL/Fedora) or /etc/php/7.4/fpm/pool.d/www.conf (under Ubuntu/Debian/Mint). The path may vary according to the php version used.
$ nano /etc/php-fpm.d/www.conf [On CentOS/RHEL/Fedora] $ nano /etc/php/7.4/fpm/pool.d/www.conf [On Ubuntu/Debian/Mint]
How to proceed?
Just look for the following directives inside the configuration file and set an appropriate value according to your use-case. In the case of directives that have already been commented, it will be sufficient to remove the comment.
pm = ondemand pm.max_children = 80 pm.process_idle_timeout = 10s pm.max_requests = 200
What do the directives indicate?
The directive pm determines how the process manager controls the number of child processes. The default method is dynamic: it means that the number of children (child processes) is set dynamically and depending on other directives in the configuration, such as pm.max_childrenthe directive that defines the maximum number of children that can be used at the same time.
For optimal memory consumption we recommend the process manager on demand: No children are created when the service starts but they are only created if needed. Child processes are created only in case of new requests, respecting the directives pm.max_children And pm.process_idle_timeout. The latter defines the number of seconds after which an inactive process is terminated.
The parameter pm.max_request defines the number of requests each child process should make before being recreated. This parameter can be used as a workaround for memory leaks caused by third party libraries.