PHP-FPM workers

PHP-FPM workers are processes that each handle one PHP request at a time. Any request that misses cache needs a free worker. If you set too few, new requests wait in a queue. If you set too many, the server can run out of RAM and start swapping. The main setting is pm.max_children. On LiteSpeed, the lsphp pool works the same way under a different name.

A common mistake is raising the child count without checking memory. Sixty-four children on a 2 GB VPS can easily exhaust RAM once you multiply by each process size. Leave headroom for MariaDB, the operating system, and backups. On shared hosting, CloudLinux LVE already limits your resources, so raising children inside that cap only increases contention.

ps aux | grep -c php

That command shows a snapshot of PHP-related processes, including the grep line itself. It is not the same as pm.max_children. Compare the count with the value in your pool config, MultiPHP settings, or lsphp settings. If the count sits at the cap during a traffic bump and TTFB rises, you may be worker-bound—or lock-bound, which can look similar until you check slow queries. If the count stays low and TTFB is still high, workers are probably not the main issue.

Choose a process manager mode that fits your traffic

pm = ondemand works well on smaller servers because children start when needed and exit when idle. dynamic keeps a few workers warm for quicker response. static is better when you have sized the box carefully and want a fixed pool. None of these modes replace good caching. LSCache serving HTML without PHP is the real capacity gain. If a logged-out homepage still runs PHP, fix that cache miss before you raise the pool.

wp-admin is uncached on purpose. Sizing workers around a slow admin screen is a quick way to OOM the server. Size for the concurrent uncached PHP you actually need—checkout, search, logged-in pages, and cron—after public pages hit cache.

Shared hosting limits versus a VPS pool

On LogicWeb shared hosting, CloudLinux LVE and the lsphp limits in MultiPHP Selector set the ceiling. You cannot create a large custom pool on a shared node. If the selector already shows the plan limit and anonymous pages still miss cache, fix LSCache rather than the child count. On a VPS you control the pool file. After changing pm.max_children, restart PHP-FPM; a graceful reload is usually enough. Watch free -h through about ten minutes of real traffic before raising it again.

A queue of requests with idle CPU often points to a lock inside PHP or a wait on MySQL, not a missing worker. Adding children in that case can make the lock worse. Check the slow query log and your object cache before the next increase.