Blog

A Linux desktop can feel slow even when the CPU is not the limiting factor. Dozens of browser tabs, a nearly full drive, frequent swapping, or a background indexing service can all make a capable machine hesitate. Start by measuring what is under pressure before changing settings.

Performance tuning should not come at the expense of reliability or security. Avoid random “speed-up” scripts that clear caches, disable important services, or change kernel settings without explaining the consequences. Small, reversible changes based on actual observations are easier to test and undo.

Establish a baseline before tuning

Run a few checks while the system is idle, then repeat them when the slowdown appears. Most Linux distributions include the basic tools required.

uptime
free -h
df -h
top

uptime shows the load average: the number of runnable or uninterruptible tasks over one, five, and fifteen minutes. A load average above the number of available CPU threads may indicate contention, but it does not prove that the CPU is the problem. Tasks waiting for disk input/output can raise the load average too.

free -h reports memory and swap use. Linux deliberately uses otherwise idle RAM for filesystem cache, so high “used” memory is not automatically a problem. Focus on available memory and on whether swap usage continues to rise during ordinary work. df -h shows free filesystem space; a root filesystem close to full can interfere with updates, logs, temporary files, and application behaviour.

Use a process viewer to find active pressure

top is available on most systems. Press P to sort by CPU use and M to sort by memory use. If it is installed, htop provides a clearer interactive view. Look for patterns before stopping anything:

• A compiler, virtual machine, browser, or database may legitimately use significant resources while it is working.
• A process that uses CPU continuously while the machine is otherwise idle deserves investigation.
• A service that repeatedly restarts can create ongoing load and rapidly fill logs.
• Several processes in uninterruptible sleep, often marked D, can indicate delays involving storage or network-mounted filesystems.

Before acting on a process that looks unusual, check its command and owner:

ps -p PID -o pid,user,%cpu,%mem,etime,command

Replace PID with the real process ID. Stop only software you recognise and are authorised to manage. On a personal workstation, closing an unused application is usually safer than killing its process because it gives the application a chance to save its state.

Keep storage healthy and leave working room

Storage affects startup time, package installation, browser caching, builds, and swap behaviour. SSDs are generally more responsive than mechanical hard drives for random reads and writes, but both can perform poorly when nearly full or when hardware errors occur.

Start by checking filesystem use:

df -h
du -xh "$HOME" 2>/dev/null | sort -h | tail -n 20

The second command helps identify large paths in your home directory. Review the results before deleting anything. Old downloads, duplicate virtual machine images, build artifacts, container images, and large log files are common cleanup candidates. Project output can often be regenerated; personal data cannot.

Manage package and log growth carefully

Some package managers retain downloaded packages and older dependencies. Use the cleanup command documented for your package manager, and read the proposed changes before confirming them. On Debian- and Ubuntu-based systems, cleaning the package cache and removing no-longer-needed packages can recover space, but do not remove packages blindly from a production machine.

On systemd-based distributions, check journal size with:

journalctl --disk-usage

Adjust log retention through the journal configuration or by using a deliberate vacuum command. Do not delete active log files underneath running services. If logs are growing unusually quickly, find the cause: repeated authentication failures, a crashing service, or a failing disk may be responsible.

For drives that support SMART monitoring, status information can reveal warnings such as media errors or reallocated sectors. Make sure a backup exists before investigating a drive that may be failing. Tuning cannot compensate for unreliable hardware.

Reduce startup work without disabling core services

A slow boot often comes down to a service waiting for a network device, a failed mount, or a desktop component that starts unnecessarily. On systems that use systemd, inspect boot timing with:

systemd-analyze
systemd-analyze blame

The first command gives an overall timing view. The second lists units by the time spent starting. Treat the output as a clue rather than a removal list: because services start in parallel, a long-running unit is not always the cause of the total boot delay.

Inspect a specific service with:

systemctl status service-name

If you confirm that a nonessential service is unnecessary, disable it through the distribution’s service manager and document the change. Do not disable networking, login management, storage, updates, time synchronisation, or security-related services just to improve a benchmark. A developer workstation may need Docker, database servers, or virtual machine tools; turning them off when unused can reduce idle memory use, but they should remain easy to re-enable for project work.

Make memory pressure visible

When RAM is limited, Linux moves less-active memory pages to swap. This can prevent abrupt application failures, but sustained swapping can make a desktop feel unresponsive, especially when swap is on a hard drive. Check swap activity with:

free -h
vmstat 1

In vmstat, nonzero si and so values over time show that pages are moving into and out of swap. Close memory-heavy programs, reduce the number of browser tabs, or allocate less RAM to a virtual machine before changing kernel parameters. If normal tasks regularly exhaust physical memory, adding RAM may be the upgrade that makes a real difference.

The vm.swappiness setting affects how readily the kernel uses swap. The best value depends on the workload, installed RAM, storage speed, and distribution defaults. Lowering it may reduce swap preference on a desktop, but it does not create memory. Test a temporary value first, observe it through a complete workload, and record the original setting.

Applications matter as much as system settings. A browser profile with many extensions can use more memory than the browser engine itself. Development tools may leave language servers, indexers, emulators, and containers running after a project closes. Check their settings for resource limits or automatic shutdown options before assuming the operating system is at fault.

Improve desktop responsiveness

Graphical effects are rarely the largest performance cost, but they can be noticeable on older integrated graphics or in virtual machines. A lightweight desktop environment can reduce idle RAM and GPU demand. Before changing desktops, try smaller adjustments: reduce animation effects, remove unused panel widgets, and verify that display resolution and refresh rate are set correctly.

Drivers can also affect graphics and Wi-Fi performance. Prefer drivers provided through distribution repositories or the hardware vendor’s official channel. Avoid copying kernel modules or graphics tweaks from unverified posts. A mismatched driver can lead to freezes, boot failures, or reduced update support.

Laptop users can balance responsiveness against battery life with the active power profile. Performance modes may help under load, while balanced modes can reduce heat and fan noise. Test changes while compiling code, running a local development server, or doing another realistic task instead of judging them only by idle CPU frequency.

Use updates and maintenance as performance tools

Updates can fix memory leaks, filesystem bugs, driver regressions, and inefficient application behaviour. Install them through trusted distribution repositories, preferably after backing up important projects. Restart when an update affects the kernel, graphics stack, or a foundational library.

For developer tools, remove SDK versions, extensions, and runtimes you no longer use. Before clearing old dependencies, record the versions required by active projects in project documentation or configuration files. That keeps a storage cleanup from turning into a broken build environment.

Benchmark a real workload, not only a synthetic score

A change matters only if it improves the work you actually do. Measure something repeatable: a clean build, application startup, test-suite duration, or boot time after a restart. Run each test several times because filesystem caches and background jobs can affect individual results.

Keep a short change log with the date, command or setting changed, original value, and observed result. For example, after removing an unused local database service, reboot once, run the same project build three times, and compare the median time with the recorded baseline. That record helps you keep changes that work and reverse those that only appeared helpful.