As a WordPress developer who manages servers via SSH, understanding Linux process management is essential for diagnosing slow sites, killing runaway PHP processes, managing web server daemons, and automating maintenance tasks. Every running program on a Linux system is a process with a unique process ID (PID), and the OS scheduler decides how much CPU time each process gets. When your WordPress site is slow, it may be because a PHP-FPM worker is stuck, a MySQL query is running for minutes, or a rogue cron job is consuming all available memory. The tools you need are: ps (list running processes), top or htop (real-time CPU/memory usage), kill (send signals to processes), systemctl (manage systemd services), and journalctl (view service logs). On Ubuntu/Debian servers (the most common hosting OS for WordPress), Apache is managed as apache2 and MySQL as mysql or mariadb via systemctl. PHP-FPM is a separate service, typically named php8.1-fpm or similar. Combine this knowledge with the essential Linux commands, the bash backup script, and WP-CLI for a complete server management toolkit.
Problem: Your WordPress server is slow or unresponsive and you need to find and manage runaway processes, restart services, and diagnose high CPU or memory usage from the command line.
Solution: Use the following Linux commands via SSH:
# ── List processes ────────────────────────────────────────────────────────────
ps aux # all processes with CPU/memory usage
ps aux | grep php # filter for PHP processes
ps aux --sort=-%mem | head -10 # top 10 processes by memory
# ── Real-time process viewer ──────────────────────────────────────────────────
top # built-in (press q to quit)
htop # enhanced version (sudo apt install htop)
# ── Find a specific process ───────────────────────────────────────────────────
pgrep -fl mysql # find MySQL process IDs and names
pidof apache2 # get PID of Apache
# ── Kill a runaway process ────────────────────────────────────────────────────
kill 1234 # graceful termination (SIGTERM) for PID 1234
kill -9 1234 # force kill (SIGKILL) if graceful fails
pkill php # kill all PHP processes by name
killall php-fpm8.1 # kill all PHP-FPM 8.1 worker processes
# ── Manage services with systemctl ───────────────────────────────────────────
sudo systemctl status apache2 # check if Apache is running
sudo systemctl restart apache2 # restart Apache (applies config changes)
sudo systemctl reload apache2 # reload config without dropping connections
sudo systemctl stop mysql # stop MySQL
sudo systemctl start mysql # start MySQL
sudo systemctl enable apache2 # start Apache automatically on boot
sudo systemctl disable apache2 # prevent auto-start on boot
# ── View service logs ─────────────────────────────────────────────────────────
sudo journalctl -u apache2 -n 50 # last 50 lines of Apache log
sudo journalctl -u mysql -f # follow MySQL log in real time
sudo tail -f /var/log/apache2/error.log
# ── Check open ports ──────────────────────────────────────────────────────────
sudo ss -tlnp # listening TCP ports with process names
sudo netstat -tlnp # alternative (older command)NOTE: Use kill -9 (SIGKILL) only as a last resort — it terminates a process immediately without allowing it to clean up, which can cause data corruption in databases and leave lock files behind. Always try kill PID (SIGTERM) first and wait a few seconds. For MySQL specifically, a sudden SIGKILL can corrupt InnoDB tables — run mysqlcheck --all-databases --auto-repair after any forced MySQL kill. If PHP-FPM workers are frequently getting stuck, increase the request_terminate_timeout in your PHP-FPM pool configuration or investigate slow database queries.