Skip to main content

Process Control

When a server is slow, your fastest win is often identifying a single process that is consuming CPU, memory, or disk I/O. This guide shows safe patterns for inspecting processes and intervening without causing extra downtime.

Quick Summary
  • Find the culprit with ps, top, htop, and pgrep.
  • Prefer graceful stops (SIGTERM) before force (SIGKILL).
  • Use nice/renice and ionice to reduce impact instead of killing.
  • For managed services, use systemctl and journalctl.

See what is happening now

top-and-ps-snapshot.sh
uptime
top -b -n 1 | head -n 30
ps -eo pid,ppid,user,stat,pcpu,pmem,etime,cmd --sort=-pcpu | head -n 20
ps -eo pid,ppid,user,stat,pcpu,pmem,etime,cmd --sort=-pmem | head -n 20

Find processes by name

find-process-by-name.sh
pgrep -a php-fpm || true
pgrep -a mysqld || true
pgrep -a nginx || true

If you need a full tree (parent/child relationships):

process-tree.sh
pstree -ap | rg -n 'php-fpm|mysqld|nginx'

Inspect a specific PID

inspect-one-process.sh
PID=12345

ps -p "$PID" -o pid,ppid,user,stat,pcpu,pmem,etime,cmd
sudo lsof -p "$PID" | head -n 40
cat "/proc/$PID/status" | sed -n '1,40p'

Adjust priority instead of killing

If a backup job is running during peak traffic, deprioritizing it can stabilize the server.

CPU priority

lower-cpu-priority-with-nice.sh
nice -n 10 tar -czf /backups/site.tar.gz /var/www/html

For a process already running:

renice-a-running-process.sh
sudo renice +10 -p 12345

Disk I/O priority

lower-io-priority-with-ionice.sh
sudo ionice -c2 -n7 -p 12345

Stop a process safely

Preferred: terminate gracefully

terminate-process-safely.sh
PID=12345
kill -TERM "$PID"
sleep 2
ps -p "$PID" || echo "process exited"

Last resort: force kill

warning

kill -KILL (-9) can cause data loss if the process is writing files or databases. Use it only when graceful termination fails.

force-kill-process.sh
PID=12345
sudo kill -KILL "$PID"

Managed services: use systemd

If the process belongs to a service, treat it as a service.

service-status-and-restart.sh
sudo systemctl --no-pager --full status php8.2-fpm || true
sudo journalctl -u php8.2-fpm --since '30 minutes ago' --no-pager | tail -n 200

sudo systemctl restart php8.2-fpm
sudo systemctl is-active php8.2-fpm

Common WordPress culprits

  • PHP-FPM worker exhaustion (too few workers, slow DB, slow disk).
  • MySQL slow queries (missing indexes, heavy cron tasks).
  • Backup/compression jobs (tar/zip/gzip/xz/zstd).
  • Malware scans or recursive file walkers.

Next steps

  • If the culprit is disk-heavy: see [Disk I/O troubleshooting](./disk-io-troubleshooting).
  • If you need a trend view: see [Historical performance stats](./historical-performance-stats).