A user says the Linux server is running slow. What do you check first?
Questions like this can come up in interviews for Linux support, technical support, junior sysadmin, and cloud support roles. Every interviewer is different, so I can't promise you'll hear this exact one. But the skill behind it shows up constantly in real support work, which makes it worth practicing.
Most people's first instinct is one word: "top."
And that's not wrong. top is a good tool. It shows load, CPU, memory, and running processes on one screen.
It's just incomplete. Not because the command is bad, but because a one-word answer doesn't show how you think.
What interviewers are often listening for
In a lot of troubleshooting questions, the interviewer cares about more than whether you remember a command. They want to hear how you approach a problem: how you gather information, how you narrow down the possible causes, and whether you can explain your reasoning as you go.
Not everyone interviews the same way, but that's a common thread. Here's a simple structure you can use.
1. Clarify what "slow" means
"Slow" is a symptom, not a diagnosis. Before you touch the keyboard, ask:
What's slow? Logging in, a web page, a script, a database query?
When did it start?
Did anything change recently, like an update, a deployment, or a jump in users?
Asking these isn't stalling. It's the first step of troubleshooting, and it's easy to skip when you're nervous.
2. Figure out the scope
Is it one user or everyone? One application or the whole server? One server or several?
A whole-system problem points you toward resources like CPU, memory, and disk. A single-application problem sends you to that application's service and logs sooner.
It's also worth asking whether the server is slow or the network between you and the server is. If the server responds quickly once you're logged in, that's a clue.
3. Check the load
uptime shows load averages for the last 1, 5, and 15 minutes. Compare them to the number of CPU cores (nproc tells you). A load of 4 means something different on a 2-core server than on a 16-core one. Also notice whether it's rising or falling.
One thing that trips people up: on Linux, load includes processes waiting on disk, not just processes using the CPU. So high load doesn't always mean a busy CPU.
4. Check the big three: CPU, memory, disk
CPU:
toporhtop. Look at the CPU line. Highusorsymeans the CPU is busy. Highwameans it's waiting on I/O, usually disk.Memory:
free -h. Look at the "available" column, not "free." Linux uses spare memory for caching, so a low "free" number alone isn't a problem. Heavy swapping is the thing to watch.Disk:
df -hshows whether a filesystem is full. If it is,duhelps you find what's eating the space. If the disk isn't full butwais high, disk speed may be the bottleneck.iostat -xcan help there, though it comes from the sysstat package, which might not be installed.
5. Find who's responsible: processes, services, logs
Processes:
ps aux --sort=-%cpu | headshows the biggest CPU users. Swap in-%memfor memory. Then ask: is this process supposed to be doing that? A backup job might be normal. A runaway script isn't.Services:
systemctl status <service>andsystemctl --failedshow what's unhealthy.Logs:
journalctl -u <service> --since "1 hour ago"shows what a service has been saying lately.journalctl -p err -bshows errors since the last boot.dmesgshows kernel messages, like out-of-memory kills or disk errors (it may needsudo).
Logs answer "what happened, and when?" Look around the time the slowness started.
6. Let the evidence pick the next step
The goal isn't to run every command every time. Each check should change what you do next:
High load, mostly idle CPU, high I/O wait: look at the disk.
Memory nearly gone and heavy swapping: find the process, and check for out-of-memory messages.
One process pinning a CPU: is it supposed to be doing that, and who owns it?
Everything on the server looks normal: go back to scope. It might be the application, the database, DNS, or the network.
What a stronger answer sounds like
"Before I run anything, I'd clarify what 'slow' means. Is it one application or the whole server, when did it start, and did anything change recently? Then I'd check load with uptime and compare it to the number of CPU cores, and look at CPU, memory, and disk with top, free, and df. From there I'd narrow it down: find the processes using the most resources, check whether the relevant services are healthy, and read the logs from around when the slowness started. What I'd do next depends on what those checks show. For example, high load with a lot of I/O wait would point me toward the disk, while heavy swapping would point me toward memory and a specific process."
That's long for a nervous moment, so here's a shorter version:
"I'd start by clarifying what's slow and whether it's one app or the whole system. Then I'd check load, CPU, memory, and disk, find which process or service is responsible, and confirm it in the logs before deciding on a fix."
You don't need to memorize either one. Practice the order.
Try this
On a Linux machine you're allowed to run commands on, run:
uptime
free -h
df -h
ps aux --sort=-%cpu | head -5Then write two sentences: what does this machine look like right now, and what would you check next? Then say your answer out loud once. It feels awkward. That's the point.
If you want more practice
I put together the SecureByDefault Linux Support Interview Prep Pack for people preparing for Linux support, technical support, junior sysadmin, cloud support, and entry-level infrastructure roles. It's $19, and it includes:
42 Linux interview questions with explanations
12 realistic troubleshooting scenarios
Linux permissions and command reference material
Rapid-review sections
A structured 7-day interview prep plan
Mock interview practice
A final interview-day checklist
It won't guarantee anything, and no pack can tell you exactly what a particular interviewer will ask. What it gives you is structured practice with questions and scenarios like the one in this issue.
If you'd like to try before you decide, there are free sample questions with answers on the SecureByDefault site.
Talk soon,
Ron
SecureByDefault
Sources
Linux man pages (man7.org): top, ps, free, df, journalctl, dmesg, and vmstat
Brendan Gregg, "Linux Load Averages: Solving the Mystery": brendangregg.com