When a Linux web server slows down, I first want to know what is waiting. Is the CPU busy doing useful work, are processes short of memory, is storage holding up requests, or is the application waiting for another service? Those problems need different fixes.
Changing several settings at once can make the server feel better without explaining why. I start with a short observation window during the problem, keep the output private and record the affected request or job.
Take a small, repeatable baseline
These commands read the current system rather than changing its configuration. Some tools may need installing through your distribution’s package manager.
date -Is
uptime
free -h
vmstat 1 10
df -h
df -iRead several samples. The first vmstat report includes averages since boot; subsequent interval samples are more useful for a current incident. Record how the website behaves during the same window. A quiet sample taken after the problem stops is a different observation.
Do not treat low free memory alone as a fault: Linux uses memory for cache. Look at available memory, activity moving pages into and out of swap, application latency and any out-of-memory events together. Likewise, space and inode capacity are separate checks.
Separate CPU work from waiting
Load average is not a CPU percentage. Use it as a prompt to inspect the running and waiting work. A server can have a busy queue while much of its time is spent waiting for storage.
Where Linux pressure information is available, it adds another view:
for resource in cpu memory io; do
pressure="/proc/pressure/$resource"
[ ! -r "$pressure" ] || cat "$pressure"
doneThe kernel’s pressure interface reports time tasks spend stalled on a resource. Compare the recent averages with the affected period. Missing files mean the interface is unavailable in that environment; they do not mean there is no pressure. A container or restricted shell can also show a different view from the host.
For more detail, iostat -xz 1 10 and pidstat -dru 1 10, from sysstat, can help connect activity to devices and processes. No single utilisation number establishes the cause. Match the samples to a workload you can identify.
Follow the queue back to its owner
If PHP requests are queuing, inspect the pool and the slow requests before increasing its worker limit. More workers can create more simultaneous database work and higher memory demand. They only help if the rest of the system has room for them.
PHP-FPM provides a maximum child-process setting and slow-request logging. Use those diagnostics through a protected management route; do not publish status pages or request details on the open web. Check the configuration used by the web process, which may differ from the command-line PHP installation.
Repeated background jobs deserve the same scrutiny. If an import takes longer than its schedule interval, more launches can become a growing queue. Check whether the scheduler prevents overlap and whether the job can resume from a saved position. Raising concurrency is not a repair for work that never finishes.
Make one change and compare the same task
Choose a change that addresses the evidence: reduce overlapping jobs, fix a slow query, correct a cache problem or add capacity to a measured constraint. Save the previous setting and decide how to undo the change before applying it.
Repeat the same representative request or job, with a similar cache state and load. Keep both the user-facing time and the resource samples. A lower CPU graph is not a win if the queue now takes twice as long to finish.
My sign-off is specific: which task improved, what changed, what the measurements showed and what remains uncertain. That gives the next investigation a useful starting point instead of another unexplained tuning value.
Further reading: Linux pressure stall information and PHP-FPM configuration.