pm

• Coose how the process manager will control the number of child processes.
• Possible values: static, ondemand, dynamic.
• The widely used values are static and dynamic
• This option is mandatory.
  • static - the number of child processes is fixed (pm.max_children).
    • In this mode requests don’t need to wait for new processes to startup, which makes it the fastest approach.
    • If you have a high traffic website, then use static and adjust the settings based on your needs over time and your available hardware resources.
    • It might seem like overkill to have a large number of child processes always ready to receive requests.
    • However, high-traffic sites need to respond as quickly as possible.
    • Therefore, it’s essential to use static so that a sufficient number of child processes are ready to do so.
    • Static was the best choice when the number of concurrent requests was relatively close to the max_children value.
    • A "fixed number of processes" always runs (best for 'steady, high traffic')
    • Static (pm=static) means no new process creation lag during high traffic.
    • Set pm=static in your PHP-FPM pool config for sites with steady, heavy loads.
  • ondemand - the processes spawn on demand (when requested, as opposed to dynamic, where pm.start_servers are started when the service is started.
    • no children are created at startup.
    • Children will be forked when new requests will connect.
    • If you have a low traffic site, such as one hosting a backend control panel, such as cPanel, then use ondemand.
      • Memory will be saved as child processes will only be spawned when they’re needed and killed off when they’re no longer required.
      • As it’s a backend, users can wait a moment or two longer while a thread spawns to handle their request.
    • By using ondemand, child processes will likely consume too much memory being spawned and killed, and the startup delay will have a performance hit.
    • This option is ideal (again, in theory) for small and medium-sized apps that don't have that much traffic, for staging environments, or for servers where multiple tenants share resources.
    • Since the child processes are recycled all the time, this option can help control any memory leaks you might be experiencing since the process will be terminated before there is time for memory to accumulate.
    • The drawback to this option is that new processes will have to be forked all of the time, and that might affect your performance and ability to respond to requests more quickly.
    • if we plan to use the pm = ondemand option, there is just one additional setting we should consider using, and that's pm.process_idle_timeout.
    • Since child processes are spawned and terminated all the time when using the ondemand option, the process_idle_timeout settings tell PHP-FPM when to terminate a child process if it's idle (not actually being used).
    • By default, that is set to 10 seconds, but you can amend that value as you please if needed, although the default is pretty sensible.
    • The tests showed that the ondemand option was the best choice when the number of concurrent requests greatly exceeded our max_children value and when the number of concurrent requests was significantly lower than the max_children value.
    • Creates "processes" only when needed (best for 'low-traffic sites')
  • dynamic - the number of child processes is set dynamically based on the following directives: pm.max_children, pm.start_servers, pm.min_spare_servers, pm.max_spare_servers.
    • In this mode, PHP-FPM dynamically manages the number of available child processes and ensures that at least one child process is always available.
    • Using dynamic likely won’t be as bad, depending on the configuration. However, you may end up with a configuration that effectively mirrors static.
    • In most cases, the dynamic will be set by default.
    • if we use pm = dynamic, there are a few additional settings to reconsider.
    • First, pm.start_servers is the number of child processes that will be spawned right away when you start or restart PHP-FPM.
    • Next, we have pm.min_spare_servers.
    • That will set the minimum amount of idle child processes.
    • And in the end, there is a pm.max_spare_servers setting that will determine the maximum amount of idle child processes.
    • Changes "process count" based on traffic (best for 'changing loads')

pm.max_children

• This setting controls the maximum number of child processes that PHP-FPM can spawn.
• The maximum number of children that can be alive at the same time.
• The number of child processes to be created when pm is set to static and the maximum number of child processes to be created when pm is set to dynamic.
• A good starting point is to set this to the number of CPU cores on your server.
• Set this too high and your server will crash, set this too low and again your server will crash.
• This is heavily dependant on how much RAM your server has, how many CPU’s and what application is it running i.e. WordPress, Magento etc.
• The more you increase pm.max_children the more RAM will be used.
• Make sure your server has enough memory to handle that.
• In a test case, with pm.max_children=2500, ~16GB RAM is used.
  • And, the CPU usage went down to around 30%.
• Set based on max usage of pm dynamic or ondemand and then increase to the point where memory and CPU can process without becoming overwhelmed.
  • You will notice that with pm static because you keep everything sitting in memory, traffic spikes over time cause fewer spikes to CPU and your server’s load and CPU averages will be smoother.
• Use 'Total PHP-FPM Memory Budget ÷ Average Process Size ÷ Number of Sites (if multi-tenant)
• High CPU Usage Messages: Entries show "server reached pm.max_children".
  • They know your server wants to create more PHP processes than allowed.
• Too low causes delays and too high risks memory problems.
• If each PHP process uses about "128MB" and you have "2GB RAM" for PHP, set this to '~12-15'.