Short answer: with atop and sar you can look back hours later. Install atop (dnf install atop from EPEL, or apt install atop) and make sure its logging service runs: systemctl enable --now atop. It writes a snapshot of every process every 10 minutes to /var/log/atop/atop_YYYYMMDD. Later, atopsar -O -r /var/log/atop/atop_YYYYMMDD -b 03:00 -e 04:00 lists the top three CPU users for each interval. atop -r FILE -b 03:00 opens that moment interactively, and t and T step forward and back. sysstat’s sar gives you averages for CPU, load, memory and disk, but it cannot name the process.
Applies to atop 2.7.1 (EPEL 9) and sysstat 12.5.4 on AlmaLinux 9.8 with cPanel 138; Debian 12: atop 2.8.1, sysstat 12.6.1; lab test 11 Oct 2026
We tested this on our cPanel lab (AlmaLinux 9.8, 4 cores) on 11 October 2026. We set atop to log every 60 seconds, ran a CPU burner for 150 seconds, and then looked for it in the logs.
Table of Contents
Why atop and sar history matters
Load problems rarely happen while you are watching. By the time a customer reports “the site was down at 3 a.m.”, htop shows a quiet server. Two tools keep history:
| Tool | Records | Names the process? | Default interval |
|---|---|---|---|
| atop (logging service) | Every process: CPU, memory, disk, plus the system totals | Yes | 600 s on AlmaLinux 9 EPEL (LOGINTERVAL) |
| sysstat (sar) | System totals: CPU, load, memory, swap, disk, network | No | 10 minutes (sysstat-collect.timer) |
Use both. sar is cheap and good for trends, atop answers “who”.
Set up atop logging
# AlmaLinux / Rocky / CloudLinux
dnf install epel-release && dnf install atop
systemctl enable --now atop
# Debian / Ubuntu
apt install atop
systemctl status atop # check that logging is activeOn AlmaLinux 9 the EPEL package installed atop.service disabled. Until you enable it, nothing is recorded. Its settings are in /etc/sysconfig/atop (on Debian, /etc/default/atop):
LOGOPTS=""
LOGINTERVAL=600 # seconds between snapshots
LOGGENERATIONS=28 # days of files to keep
LOGPATH=/var/log/atop600 seconds is a sensible default. A shorter interval catches short spikes but uses more disk: our 60-second test produced about 15 KB per sample on a quiet server. After changing it, run systemctl restart atop. A daily job (/etc/cron.d/atop.daily on our lab) starts a new file each day.
Memory note: ps showed the interactive atop at about 228 MB RSS, far more than htop (5 MB). The same amount appeared as VmLck in /proc/PID/status, and only 5 MB was its own memory (RssAnon). atop locks its pages into RAM so it keeps running when the server is short of memory, so most of that figure is locked, shared library pages rather than extra memory use.
Find the culprit: atopsar -O
The quickest answer is the top-three list per interval. This is the real output from our test, with the burner (PID 647167) running from 05:47:22:
atopsar -O -r /var/log/atop/atop_20261011 -b 05:48 -e 05:51
05:48:20 pid command cpu% | pid command cpu% | pid command cpu%_top3_
05:48:20 647167 sh 96% | 47208 mongod 1% | 647276 glances 1%
05:49:20 647167 sh 100% | 47208 mongod 1% | 584 NetworkM 0%
05:50:20 647167 sh 54% | 647605 python3 3% | 647531 sw-engin 2%The 54% in the last row is because the burner stopped halfway through that interval. Other atopsar reports cover the rest of the system:
| Command | Shows |
|---|---|
atopsar -O | Top 3 processes by CPU |
atopsar -G | Top 3 by memory |
atopsar -D | Top 3 by disk |
atopsar -c | CPU use per core |
atopsar -p | Load average and context switches |
atopsar -m | Memory and swap |
atopsar -d | Disk utilisation |
Always add -r FILE to read a log, and -b/-e (begin/end, HH:MM) to limit the time.
Look around that moment: atop -r
atop -r /var/log/atop/atop_20261011 -b 03:00This opens the snapshot nearest to 03:00 in the normal atop screen. Then:
- t / T: next / previous snapshot.
- b: jump to another time.
- C / M / D: sort processes by CPU / memory / disk.
- c: show the full command line, which shows the PHP script or cron command.
- u: totals per user, which on a hosting server means per account.
- p: totals per program.
To filter by machine, use parseable output. For example, every process that used more than 20 seconds of CPU in an interval:
atop -r /var/log/atop/atop_20261011 -b 03:00 -e 04:00 -P PRC \
| awk '$1=="PRC" && ($11+$12) > 2000 {print $4, $5, $7, $8, $11+$12}'In the PRC lines, fields 11 and 12 are user and system CPU in clock ticks (normally 100 per second).
sar: trends, not culprits
sysstat was already installed and collecting on our cPanel lab: the sysstat-collect.timer runs every 10 minutes and keeps 28 days in /var/log/sa/saDD (HISTORY=28 in /etc/sysconfig/sysstat).
sar -u # CPU today
sar -q # load average and run queue
sar -r # memory
sar -S # swap
sar -d -p # disk, with device names
sar -n DEV # network
sar -u -f /var/log/sa/sa10 # the 10th of this month
sar -u -s 03:00:00 -e 04:00:00Here is what sar recorded for the same test:
05:40:01 AM all 1.03 0.10 0.86 0.18 0.04 97.79
05:50:01 AM all 8.61 0.15 2.42 1.08 0.06 87.68A process that kept one of four cores at 100% for two and a half minutes appears as 8.6% user CPU in sar’s 10-minute average. sar tells you when something was wrong; atop tells you what.
Debian note: on our Debian 12 lab, sysstat was installed but disabled: /etc/default/sysstat had ENABLED="false" and the timers were off. Turn it on with sed -i 's/ENABLED="false"/ENABLED="true"/' /etc/default/sysstat, then systemctl enable --now sysstat sysstat-collect.timer sysstat-summary.timer. Debian keeps 7 days by default, in /var/log/sysstat/.
A routine for “the site was slow last night”
- Find the window with
sar -qandsar -ufor that day: when did the load or iowait jump? - Run
atopsar -O,-Gand-Dfor that window to name the top processes and their owners. - Open
atop -r FILE -b HH:MM, press c for command lines and u for per-account totals. - Match the time against the account’s access log and cron jobs; see where the logs are.
- Fix the cause: a cron schedule, a bot hitting an uncached page, a slow query, or a backup running in working hours. For the full method, see high load on a cPanel server.
Project home and manual pages: atoptool.nl.
At a glance
Frequently asked questions
How do I see which process caused high load in the past?
Enable atop logging (systemctl enable --now atop), then run atopsar -O -r /var/log/atop/atop_YYYYMMDD -b HH:MM -e HH:MM. It lists the top three CPU users for each interval. sar shows when the load was high but not which process.
How do I read an atop log file?
Run atop -r /var/log/atop/atop_YYYYMMDD, optionally with -b HH:MM to start at a time. Press t and T to move between snapshots, and C, M or D to sort by CPU, memory or disk.
Is atop logging enabled by default?
Not on AlmaLinux 9: the EPEL package installed atop.service disabled on our lab. Run systemctl enable --now atop. Check with systemctl status atop on any system.
Why does atop use so much memory?
atop locks its memory pages into RAM so it can keep working under memory pressure. On our lab, ps showed about 228 MB, but only 5 MB was its own anonymous memory; the rest was locked shared library pages.
Where does sar keep its data?
In /var/log/sa/saDD on AlmaLinux and RHEL-style systems (28 days by default), and in /var/log/sysstat/ on Debian (7 days, and collection is off until you enable it in /etc/default/sysstat).
Reading a lot of our guides? Go ad-free with srvScripts Pro for $6 a month. It also pays for new guides. Cancel any time.