Sar

Alright, let’s get our hands dirty with the plumbing of your network. When things are slow, flaky, or just plain broken, you need to know what’s talking to what. Forget the fancy GUI tools that try to pretty this up; we’re going straight to the source. For decades, the go-to for this has been netstat. It’s the old guard, and it’ll get the job done. But on modern Linux systems, we have a faster, more informative successor: ss. Think of netstat as your reliable but slightly creaky old toolbox, and ss as the shiny new socket wrench set that does the same job but better and faster. I’ll show you both, because you’ll still see netstat everywhere, but you should default to ss.

Right, let’s talk about lsof. It’s one of those tools you’ll use once a year and think, “Why don’t I use this magnificent beast more often?” Its name, lsof, is a classic piece of Unix utility naming: brutally literal. It stands for “list open files.” But on a Unix-like system, everything is a file. And I mean everything. Your hard drive? File. Your network connection? File (a socket, technically). That running process? You get the idea. This means lsof is your ultimate backstage pass to see what every process on your system is actually doing—what it’s reading, writing, and talking to. It’s the debugger’s equivalent of a truth serum.

Right, let’s talk about ltrace. If strace is the tool you use to see what your program is doing (its syscalls), ltrace is the tool you use to see what it’s thinking. It shows you all the library calls it’s making. This is where you go when your program isn’t segfaulting but is, instead, just being profoundly weird or slow. It’s like eavesdropping on your application’s conversation with the shared libraries it depends on.

Right, let’s talk about strace. You’ve probably hit a wall where your application is doing… something… but you have no earthly idea what. It’s not logging, it’s not crashing, it’s just sitting there, taunting you. This is where strace becomes your best friend. It’s the debugger of last resort, the ultimate truth-teller. It shows you the raw conversation between your program and the Linux kernel—every file it opens, every network call it makes, every time it asks the system for the time of day. It doesn’t lie.

Right, let’s talk about perf. If you’re serious about figuring out why your code is slow, leaking memory, or just generally misbehaving on Linux, this is your new best friend. It’s not a tool; it’s a sprawling ecosystem of tools built into the kernel, and it’s so powerful it’s almost absurd that it’s free. Forget guessing. We’re moving to evidence-based profiling. Think of perf as a high-speed data recorder for your CPU. It can tell you which lines of code are getting executed millions of times, what’s causing those pesky cache misses, and where the kernel is spending its time on your behalf. It does this using Performance Monitoring Units (PMUs) – hardware counters on the CPU itself. This means it’s incredibly low-overhead. We’re not talking about adding print statements here; we’re talking about directly querying the processor’s internal statistics.

Right, let’s talk about sar. This is the tool you use when you get that 3 AM alert about a server being “slow” and you need to figure out what actually happened six hours ago. While top or htop show you the glorious, burning dumpster fire of the present moment, sar is the historian who kept meticulous, if slightly dry, notes on the entire blaze. It’s part of the sysstat package, and if you’re not installing that by default on every Linux system you touch, we need to have a different conversation first.

Right, let’s talk about iostat. You’ve probably felt it—that creeping suspicion that your application is just… waiting. Waiting on what? The disk. It’s the slowest part of the whole party, and when it’s struggling, everything grinds to a halt. top might show you a sky-high %wa (I/O wait), but that’s just the headline. iostat is the full, gritty investigative report. It tells you which disk is the problem child and exactly what kind of tantrum it’s throwing.

Alright, let’s talk about vmstat. It’s one of those old-school Unix tools that has stubbornly refused to die, and for good reason: it gives you a shockingly comprehensive, low-overhead snapshot of what your system’s core components are doing at any given moment. The name stands for “virtual memory stat,” but that’s a bit of a misdirection. It’s like calling a Swiss Army knife a “blade holder.” Sure, virtual memory stats are in there, but you’re also getting CPU, swap, and block I/O—all in one dense, text-based punch.