Guide Monitor CPU, RAM and Disk Usage in aaPanel - Printable Version +- AdminsForum (https://adminsforum.com) +-- Forum: Free & open-source control panels (https://adminsforum.com/Forum-free-open-source-control-panels) +--- Forum: aaPanel (https://adminsforum.com/Forum-aapanel) +---- Forum: aaPanel Guides & Tutorials (https://adminsforum.com/Forum-aapanel-guides-tutorials) +---- Thread: Guide Monitor CPU, RAM and Disk Usage in aaPanel (/Thread-guide-monitor-cpu-ram-and-disk-usage-in-aapanel)

Monitor CPU, RAM and Disk Usage in aaPanel - DEV - 10-11-2026 Quick answer Use Home for a current resource overview, then Monitor for historical activity. Enable Monitoring Status before relying on historical charts. Compare the time when the website was slow with CPU, memory, disk and network activity; a single high reading does not identify the cause by itself. What was checked We opened Home and Monitor on the AdminsForum lab running aaPanel 8.0.6. Monitoring was initially off. We enabled it and received the successful status message, leaving the existing 30-day retention unchanged. Newly enabled monitoring initially showed No Data; that is shown honestly in the screenshot. This guide does not claim that an alert or a simulated overload was tested. 1. Start with the Home overview Sign in to aaPanel and click Home. Note the CPU core count, CPU usage, RAM usage and the used/total space on the root filesystem. Write down the time of the problem before refreshing or changing anything. AdminsForum lab resource overview. These readings are a momentary sample from the lab, not performance targets. Our lab has two CPU cores, around 3.82 GB of RAM and a root filesystem of around 38.3 GB. Its low load and available disk space at this moment do not prove that it was healthy during an earlier slowdown. That is why history matters. 2. Enable historical monitoring Click Monitor in the left-hand menu. Check the Monitoring Status switch. If it is off, turn it on and wait for the success message. Keep collection enabled when you need to investigate recurring problems. AdminsForum lab: monitoring enabled with 30-day retention. The charts initially have no historical samples. The Number of days to save box controls retention. If you change it, click Modify and check the resulting status. Choose a period that covers the pattern you are investigating, while watching the Monitor Log Size. We left the lab's value at 30 days; we did not test a retention change. 3. Select the time of the problem Each chart has Yesterday, Today, Last 7 days and Custom controls. Use Today for a current issue and a longer range for recurring daily spikes. Keep the same time range across the charts so you compare the same incident. Remember that server time and your local time may differ. When monitoring has only just been enabled, older activity cannot be reconstructed from those new samples. Allow collection to run, return later and refresh the relevant chart. If No Data persists, verify the switch is still on and inspect the panel logs rather than repeatedly clearing data. 4. Read CPU and load together A short CPU spike during installation, a backup or a scheduled job can be expected. Sustained high CPU during normal traffic deserves investigation. Load average and CPU percentage are different measurements. Check trends and the server's core count rather than assuming any non-zero load is a fault. Record which operation was running at that time. If a backup overlaps a busy period, move the job to a quieter window after confirming the relationship. If slow pages and high CPU recur together, investigate PHP requests, database queries or unexpected processes. Do not increase PHP workers blindly: that can increase contention. 5. Check memory without guessing Look for memory pressure that persists during the slowdown. Linux can use spare RAM for cache, so a high used-memory figure alone is not enough to diagnose a shortage. Compare available memory, swap activity and the workload. Repeated swapping or processes being killed is more actionable evidence than one graph reading. If a PHP error says Allowed memory size exhausted, that is also a per-script limit issue. It does not automatically mean the whole VPS needs more RAM. Conversely, increasing every script's memory limit on a small server can make total memory pressure worse. Review the PHP limit and concurrent worker count together. 6. Separate disk activity from disk capacity Disk I/O describes activity; used disk space describes capacity. A busy disk is not the same as a full disk. Check both. Mail delivery, database writes, logs and backups can fail when a filesystem runs out of space. If a backup or database import coincides with heavy disk activity, record that evidence. For low free space, identify the directories using it before removing anything. Preserve needed backups, mail and website data. Do not delete unfamiliar files just to make a percentage lower. 7. Check network activity Compare upstream and downstream activity with expected traffic, downloads and backups. In Network I/O, check which interface or All selection is displayed. A traffic spike alone does not prove an attack. Correlate it with website access logs and known jobs. If the website is slow while CPU, memory and disk are quiet, also investigate DNS, connection latency, upstream services and application errors. Resource monitoring cannot diagnose every issue. 8. Gather evidence before changing settings For a support request, collect: The approximate incident time and time zone. What the visitor saw, including the exact error or HTTP status. The relevant chart range and whether the spike was brief or sustained. Any scheduled backup, install or import running then. A short relevant log extract with passwords, tokens, personal data and connection strings removed. Make one justified change at a time, then compare the same workload again. Killing a process or restarting services can interrupt users and erase useful context, so first identify what the process does. Useful read-only terminal checks If you are comfortable with the terminal, these commands complement the dashboard: Code:Copy uptime free -h df -h df -i top Use q to leave top. df -i checks inode use: a filesystem can run out of inodes even when some storage capacity remains. These commands are optional diagnostics; their output was not captured for this walkthrough. Do not confuse collection with alerts A history chart is not proof that an email notification is configured. Set up and test alerting separately if you need to be notified while away from the panel. This walkthrough enables resource collection only. Completion checklist Home overview checked and incident time recorded. Monitoring Status on and successful response confirmed. Retention reviewed. Matching chart ranges selected for investigation. Resource readings compared with logs and scheduled jobs. No monitoring history cleared during diagnosis. Reference: aaPanel official System Monitor documentation.