Ubuntu system monitor and resource management

Ubuntu’s graphical System Monitor, called Resources in recent GNOME releases, gives a live view of CPU use, memory, storage, network traffic and running processes. It is the quickest place to check whether an application is busy, whether the machine has enough available memory, or whether a service is generating unusual disk activity. Older installations may still call the tool System Monitor, so search for either name after installing the Ubuntu desktop.

For most users, resource management means noticing a slow response, identifying the process responsible and making a measured change rather than restarting everything at once. This matters on Australian broadband and office connections, where an NBN service may share household traffic, and on laptops used during hot spells in Sydney, Melbourne or Brisbane. The tools below work on a home desktop, a small business workstation and a Raspberry Pi running Ubuntu alike.

Reading the resource graphs

Open Resources and look first at the summary panels for CPU, memory, disk and network. The Processes tab gives a broader overview, while individual panels show live graphs and the processes responsible for current activity. A short spike is usually harmless; a graph that stays high for minutes tells you where to investigate. Expand a panel for per-core CPU detail or a list of active processes.

CPU percentages are easy to compare, but load average provides useful context on Linux. It represents runnable work and certain waiting tasks averaged over one, five and 15 minutes. A load of 4 on an eight-core machine may be comfortable, while the same value on a two-core machine can indicate a queue. Compare load with CPU use instead of treating either number as a performance score.

The memory panel can look alarming because Linux uses spare RAM for cache. Available memory, rather than the raw free value, is the useful figure. Watch for sustained pressure, heavy swapping and a rising queue of disk activity. The disk panel separates storage capacity from I/O, while the network panel shows traffic volume; neither graph identifies the cause on its own.

Managing processes safely

Sort the Processes table by CPU, memory or I/O, then inspect the Process ID, user, command and parent process. A high percentage alone does not identify a fault. A browser renderer, package indexer or backup agent may all look busy while doing useful work. The command line and parent process often provide the context missing from the process name.

When a program is genuinely stuck, use End Process first. It normally asks the application to close cleanly, allowing it to save work and release locks. A force-kill option is more abrupt and can interrupt a database update or file copy. Close the graphical window and wait briefly before reaching for either command.

For a terminal workflow, send kill -TERM 1234 with the relevant PID, then check whether it exited. Reserve kill -KILL 1234 for a process that ignores the polite request. Do not target kernel threads, the desktop session or a systemd unit merely because its CPU share is high. If several children belong to one service, stop the service through systemctl so its dependencies are handled correctly.

Understanding memory and swap

Linux divides memory use into applications, buffers and cache. Cache represents recently accessed data that the kernel can reclaim quickly, so it is not permanently consumed. The free -h command provides a clearer terminal view than the graph alone: check the available column, swap used and whether the cached value changes during ordinary work. A low free figure with healthy available memory is a normal state.

Swap is disk-backed memory used when the active working set does not fit in RAM. A small amount of swap use can be harmless, especially on a laptop that was previously running a large application. Continuous swapping during light work, paired with high disk wait, points to memory pressure. Some Ubuntu installations use a swapfile or partition, while others enable compressed zram; check the actual configuration before changing it.

A steadily growing process is a useful warning sign, but growth alone does not prove a memory leak. Compare it with the same workload after a restart and inspect whether available memory falls at the same rate. The kernel log can reveal out-of-memory decisions with journalctl -k -b. If more memory is needed, compare current modules and SSDs with prices from Australian computer retailers such as JB Hi-Fi; purchases made by consumers in Australia are covered by guarantees under the Australian Consumer Law.

Tracking storage, network and graphics

Begin with df -h to check mounted filesystem capacity and du -sh on a suspect directory to find large files. A nearly full partition can affect updates, temporary files and browser profiles, while high I/O wait means tasks are ready but waiting for storage. NVMe drives are fast, yet a saturated disk queue or a failing drive can still make the whole system feel stuck. Use lsblk to map devices and mount points before making a cleanup.

The Resources network graph shows current throughput, while ss -tulpn lists active TCP and UDP sockets with the owning process where permissions allow. On a busy NBN connection in an Australian home, separate local synchronisation, video calls and cloud backups before blaming the line. The nmcli device show command is handy for Wi-Fi and wired interface details. Remember that upload congestion can cause slow requests even when download speed remains high.

A browser can also become the bottleneck: a page built around animated browser games can keep CPU and graphics activity high. Test with one tab at a time and use the browser’s own task manager to identify the tab. Comparing results from different sites, window sizes or power modes produces noisy data, so keep the test conditions consistent.

For graphics diagnosis, glxinfo -B from the mesa-utils package provides OpenGL renderer details on many systems, while nvidia-smi is appropriate for supported NVIDIA hardware. Wayland and X11 can expose different behaviour, so record the session type as well as the driver. Remote desktop sessions and video editing add separate graphics loads that a CPU graph alone will not explain.

Controlling background resource use

Start with things that begin automatically. The GNOME Startup Applications utility shows user-level entries, and systemctl --user list-units --type=service --state=running reveals active background services. System-wide units appear with systemctl list-units --type=service --state=running. The systemd-analyze blame command highlights slow units during boot, which can reveal a network mount or security tool delaying the desktop.

Virtual machines, containers, file indexers, continuous backup and cloud synchronisation can consume more resources than the applications you are actively using. Pause or schedule non-urgent jobs rather than disabling them blindly. For example, move a large backup to a cooler evening or limit parallel compression. On an Australian electricity plan with usage-based charges, reducing heat-producing background work can also lower power use and fan noise.

Avoid disabling package updates, firewall components or security services to gain a small performance improvement. If a service is optional, disable it explicitly and record how to restore it; if it is required, tune its limits or repair its configuration. On a laptop, powerprofilesctl can switch between power-saving, balanced and performance modes, while sensors from lm-sensors helps connect fan speed and temperature with sustained processor load.

Using terminal tools for deeper diagnosis

The terminal can confirm what the graph suggests and preserve useful values for comparison. The uptime command shows load and uptime, free -h summarises memory, and top gives a live process view. Install htop for easier navigation and filtering. These tools use the same kernel statistics as the desktop utility, so switching interfaces does not change the underlying workload.

For trends, vmstat 1 reports CPU, memory, swap and block-I/O activity at one-second intervals. The iostat -xz 1 command from sysstat highlights active disks, utilisation and average queue depth, while pidstat -d 1 focuses on processes performing I/O. A short sample can miss an intermittent fault, so run it while the slowdown occurs. Read averages alongside current values to distinguish a brief burst from persistent pressure.

Logs connect symptoms with causes. Use journalctl -u SERVICE_NAME for a service, journalctl -k -b for kernel messages in the current boot and systemd-cgtop for control-group activity. If the desktop freezes after opening a particular application, capture memory, I/O and logs before terminating it. That sequence preserves evidence and makes it easier to distinguish a defective application from a storage or driver fault.

A repeatable troubleshooting routine

Begin with a written symptom: what became slow, when it began, and which applications were open. Record one baseline with uptime, free -h, df -h and the Resources graphs. Then reproduce the activity and note which graph changes first. A network delay after a file copy points differently from a slowdown that begins before any network request is sent.

Change one variable at a time. Close an application, stop one optional service, move a synchronisation folder or switch a power profile, then repeat the same test. For a managed service, use systemctl stop UNIT first and restart it after verification. Keep the PID, relevant log lines and before-and-after readings so the result remains useful after the session ends.

For recurring problems, define a response before saturation occurs. A scheduled backup with a concurrency limit may be better than an always-on synchroniser; a memory-heavy service may benefit from a systemd memory limit after its normal peak is known. Test limits in a non-critical session, because an overly strict cap can trigger repeated failures. Record the exact unit, setting and rollback command.

After the fix, watch the same workload for at least as long as the original problem lasted. Confirm that available memory, I/O wait and network delay have returned to their expected ranges, and check that the service starts correctly after a reboot. The dependable rule is to capture a baseline, change one component at a time, and compare the same workload before and after.