Server Mode → Monitoring → Processes shows the 10 most resource-intensive processes currently running on the server. This is the fastest way to identify what is causing a CPU or memory spike without opening an SSH session.
How It Works
The Agent queries ps aux --sort=-%cpu via its /metrics/top-processes endpoint and returns the top 10 results. The Panel displays these in a table that refreshes every 10 seconds.
Columns
| Column | Description |
|---|---|
| PID | Process ID |
| User | Linux user running the process |
| CPU% | CPU utilisation at the time of the last sample |
| MEM% | Percentage of total RAM in use |
| Command | Full command string including arguments |
The table is sorted by CPU% descending by default. Click the MEM% column header to sort by memory instead.
Common Things You Will Find Here
Runaway PHP scripts — look for php or php-fpm entries owned by a hosting account user consuming 80–100% CPU. The command string usually includes the script path. SSH in and use kill -9 PID if the process is not stopping on its own.
Slow database queries — mysqld showing high CPU often means a long-running or unindexed query. Check SHOW PROCESSLIST; in MariaDB to identify it.
Memory leaks — a process with MEM% climbing steadily over hours rather than spiking. Note the PID and restart the service gracefully before it consumes all available RAM.
Mail processing spikes — rspamd or postfix processes during a mail storm or spam run. Check mail queue size with:
postqueue -p | tail -1
Limitations
Note: You cannot kill or signal processes from the Panel. This is intentional — sending signals to arbitrary PIDs through a web UI carries too much risk of disrupting critical services. SSH into the server to terminate processes:
ssh root@your-server
kill -15 PID # SIGTERM — graceful stop
kill -9 PID # SIGKILL — force stop
The process list shows a snapshot in time. A process that spikes briefly and exits may not appear. If you see high CPU in the Monitoring charts but nothing suspicious in the process list, the offending process may have already exited — check /var/log/opterius/agent.log and system logs for context.