Linux · Systems fluency

How do you approach Linux performance monitoring and diagnosis?

HardperformanceobservabilityprofilingUpdated Oct 2026
Quiz this track

Short answer

Use a structured method such as USE: check utilization, saturation, and errors for each resource. Start with cheap counters, narrow the bottleneck, then use tracing or profiling only when needed.

Performance work starts with a question, not a tool. Define the symptom, the time window, and the affected requests. Establish a baseline, then compare CPU, memory, disk, and network behavior across that window.

sh
vmstat 1 5
iostat -xz 1 5
pidstat -u -r -d 1 5
perf top

Tools by layer

  • vmstat: run queue, context switches, swap, and I/O wait
  • iostat: per-device throughput, latency, and queue depth
  • pidstat: per-process CPU, memory, and disk over time
  • perf: sampling profiles and hardware counters
  • strace and tcpdump: syscall and packet-level detail with higher overhead

Sampling tools are usually safe in production; tracing every syscall or capturing full packets is not. Understand the overhead, duration, and data volume before running a deep tool. Flame graphs are useful for shared understanding but need a representative workload.

Averages hide tail latency. If users report slowness, inspect p95 and p99 latency, not only the mean, and align the timeline with deploys and traffic changes.

Follow-ups you should expect

Interviewers use these to check whether the first answer was understanding or memorisation.

  1. 1What is the USE method?
  2. 2When would you use strace in production?
  3. 3Why are p95 and p99 more useful than averages?
  4. 4What are the risks of profiling on a busy host?

Say it in the interview

I start from the symptom and a baseline, then use the USE method to check utilization, saturation, and errors per resource. I use cheap counters first and narrow with per-process data. Tracing and profiling come later because they add overhead. I also look at tail latency rather than only averages.

Use this as a model, not a script. Saying it in your own words is what makes it survive follow-up pressure.

Related questions

Reading is step one

Now say it out loud.

Understanding an answer and delivering it under pressure are different skills. Rehearse this topic in a live Linux mock interview and get scored feedback on depth, clarity and confidence.