Your Linux PC pauses when you open a browser tab, the fan gets loud, or a folder takes several seconds to appear. Before restarting, use btop for focused Linux performance troubleshooting: this guide shows how to reproduce the slowdown, read CPU, memory, disk, and network activity, verify clues with safe commands, and choose a careful next step.
btop is an interactive system monitor. It displays changing resource use and running processes in one view, but it does not automatically identify the cause or tell you which process is safe to stop. Think of it as a car dashboard: it shows warning signs, while you still need to connect them to what the vehicle was doing.
Why btop helps with Linux performance troubleshooting
The most useful performance evidence appears while the problem is happening. If you restart immediately, you may clear the symptom and lose the chance to see what changed. btop lets you watch the system during a repeatable action, such as opening the same project, loading a large web page, or starting a local build.
That live view helps separate a busy computer from an unresponsive application. A video export may use a processor heavily by design. A file manager that freezes while CPU and disk activity remain low may point to a different kind of delay, such as a remote location, a graphics issue, or an application problem.
Start with three questions:
- What exact action causes the delay?
- Which resource changes at the same time?
- Does the activity stop when the action finishes?
These questions turn “Linux feels slow” into an observation another person can investigate. They also reduce the risk of making a random change that hides the real cause.
Install btop from a trusted source
Use the package manager provided by your Linux distribution whenever possible. First check whether btop is already installed:
command -v btop
btop --versionOn Ubuntu or Debian, an enabled repository may provide the package with these commands:
sudo apt update
sudo apt install btopOn Fedora, use:
sudo dnf install btopPackage availability and versions vary by distribution and enabled repositories. If the package is not available, check your distribution’s documentation or the upstream btop project. Avoid adding an unknown repository or piping an unverified download directly into a shell.
Run btop as your normal user for ordinary desktop troubleshooting. You do not need administrator access to observe your own applications, and using elevated privileges can make it easier to overlook the difference between viewing a process and controlling it.
Build a repeatable slowdown test
A good test changes one variable at a time. Open btop, wait briefly while the computer is idle, and note the general pattern. Then perform one action that regularly feels slow. Use the same file, page, folder, or command if possible.
For example, suppose a developer says that opening a project takes 10 seconds. Rather than launching several applications at once, they can close unrelated work, start btop, open that project, and watch what happens during the delay. If one compiler process consumes a core and disk activity rises, that is a stronger clue than a screenshot taken after the project finally opens.
Record the observation in simple language:
- Action: open the local project folder.
- Duration: the window appears after a noticeable pause.
- Change: one process uses substantial CPU while storage activity increases.
- Comparison: closing the project and repeating the test produces the same pattern.
A second example is a browser that becomes slow after many tabs remain open overnight. If memory use grows while the system begins moving data between memory and storage, reducing tabs and repeating the test may show whether memory pressure is involved. That does not prove a memory defect; it identifies a useful direction.
Read CPU, memory, disk, and network panels together
Do not focus on the largest number in btop. Look for timing and relationships. A short spike may be normal, while a moderate level that continues throughout every interaction may be more important.
CPU usage and load
CPU activity shows how much processor work is occurring. A process that briefly reaches a high percentage during an expected task is not automatically faulty. Ask whether the process matches the action and whether the computer becomes responsive when the task ends.
On a multi-core system, one busy core can matter even when the total CPU percentage looks modest. For example, an older application may perform a task on one main thread. The whole machine may not appear fully busy, yet that application can still feel stuck.
Memory pressure and swap
Memory, often called RAM, holds data that active programs need quickly. Swap is storage space Linux can use when it needs to move less-active memory out of RAM. Swap activity can be normal, but repeated movement between RAM and storage may make an already busy system feel sluggish.
Do not interpret every “used” memory figure as a problem. Linux may use available memory for caches that can be released when applications need it. Look for the broader pattern: applications slow down, available memory falls, and swap activity rises together.
Disk activity and capacity
Disk capacity and disk activity answer different questions. A drive can be busy while it has plenty of free space, and a nearly full filesystem can be quiet at the moment you inspect it. If an application stalls while storage activity rises, identify what is reading or writing before assuming the drive is failing.
For instance, a backup job may explain heavy disk use at a predictable time. A package update may do the same. If the delay occurs only when a local database writes records, investigate that application’s workload and logs rather than stopping a random system process.
Network activity
Network traffic can explain delays involving cloud files, remote desktops, package repositories, or online services. No visible traffic does not prove that the network is healthy; an application may be waiting for DNS, a remote response, or a timeout.
Compare local and remote actions. If opening a local text file is instant but opening a mounted remote folder pauses, the resource panels are telling you that the next question may concern the connection or remote service, not local CPU speed.
Use btop findings to choose the next check
btop provides clues, so confirm them with small, read-only commands. These checks create a second view without changing system settings:
free -h
df -h
ps -eo pid,comm,%cpu,%mem --sort=-%cpu | head -n 12free -h summarizes memory in a human-readable format. Pay attention to available memory and swap information rather than treating the free column as the whole story. df -h shows filesystem capacity, which helps detect a nearly full system partition.
The ps command creates a process snapshot sorted by CPU use. Its percentages are calculated differently from a live monitor’s interval, so the two displays may not match exactly. Use the output to note process names and IDs, then repeat the slow action if you need a more accurate comparison.
For a storage clue, you can also check whether a specific filesystem is mounted as expected:
findmnt
lsblkThese commands help distinguish a local filesystem from a mounted device. They do not diagnose every storage fault, but they can prevent a mistaken conclusion about where an application is reading its files.
A practical btop walkthrough for a slow desktop
Imagine a workstation that pauses whenever a user opens a large photo folder. Here is a safe investigation path and the reasoning behind it.
- Prepare the test. Save work, close unrelated applications, and open btop as the normal user. Do not begin by killing processes.
- Repeat one action. Open the same folder twice, leaving enough time to observe each attempt. Note whether the delay is consistent.
- Compare the panels. If CPU rises, inspect the process list for the application or an expected thumbnail task. If disk activity rises, ask whether the folder is local and whether another job is scanning or copying files.
- Confirm without changing settings. Run
free -handdf -h. If memory and storage look normal, test a smaller folder and a different application. - Make one reversible change. Pause an ordinary user-initiated copy or close the application normally, then repeat the same test. Record whether the result changes.
Suppose the folder opens quickly after a background copy finishes. The copy is a plausible contributor, but you should still check whether the same delay returns during the next copy. If only one folder remains slow, file count, remote storage, thumbnails, or the application may deserve closer inspection.
As another example, a workstation may show high CPU from a build command while the editor remains responsive. In that case, high CPU is expected work, not necessarily a fault. The useful action may be to schedule large builds differently or reduce parallel work, provided the project’s normal controls support that change.
Common mistakes that make diagnosis harder
The biggest mistake is treating a monitor as an automatic answer. A process at the top of the list is not automatically dangerous, and a brief resource spike is not automatically the cause of a long delay.
- Stopping the wrong process: a service may be writing a database, updating files, or handling an important request. Save work and use the application’s normal close or stop procedure first.
- Changing several things at once: closing apps, disabling services, changing swappiness, and rebooting together makes the result difficult to interpret.
- Confusing capacity with activity: free disk space does not reveal whether storage is busy, and a quiet disk does not prove that a remote operation is healthy.
- Sharing sensitive screenshots: process lists can reveal usernames, paths, project names, command arguments, or server details. Redact them before posting publicly.
- Comparing unrelated moments: a snapshot taken after the slowdown is over may not explain what happened. Capture the system during the repeatable action.
For a production server, treat observations as operational evidence. Record the time, workload, process name, and visible symptom, then follow the service’s documented maintenance procedure. A forced stop can turn a performance question into lost data or an avoidable outage.
When btop is not enough
Sometimes the desktop feels slow while CPU, memory, disk, and network panels look ordinary. Broaden the test instead of forcing the evidence to fit one explanation. Check whether the issue affects one application, local files, remote files, or the entire desktop.
Application logs may reveal a timeout or failed connection that a general monitor cannot explain. Graphics problems, DNS waits, filesystem errors, and short-lived events may require tools designed for those areas. If the issue is intermittent, keep a short record of the action, time, and visible symptom so you can compare separate incidents.
For longer-term server trends, the Prometheus and Grafana guide covers a different monitoring approach. btop is best for an immediate, interactive view; a metrics system is more useful when you need history across hours, days, or multiple machines.
FAQ about Linux performance troubleshooting with btop
Is btop good for Linux performance troubleshooting?
Yes, btop is useful for observing CPU, memory, disk, network, and process activity while a slowdown occurs. It is a starting point rather than a complete diagnosis, so confirm its clues with repeatable tests and read-only commands.
How do I find what is slowing down my Linux PC?
Open btop, reproduce one slow action, and watch which resource changes at the same time. Then compare the process name with the action and confirm memory or filesystem details using commands such as free -h and df -h.
Should I kill the process using the most CPU?
Not automatically. High CPU use may be expected for a build, backup, export, or update, and stopping it forcefully can lose data. Close your own application normally or use the service’s documented stop procedure.
Why does Linux feel slow when CPU usage is low?
Low CPU usage can occur while an application waits for storage, a remote service, DNS, a graphics component, or another timeout. Compare local and remote actions, inspect application logs, and check whether the delay affects one program or the whole desktop.
Take the next step with evidence
Effective Linux performance troubleshooting is less about finding the biggest number and more about matching a resource change to a repeatable action. Use btop during the slowdown, confirm the strongest clue with a safe command, and make only one reversible change at a time.
Next time your Linux PC feels slow, do not restart first. Open btop, reproduce the exact delay, write down what changed, and investigate that clue before touching system settings or stopping a process.
