Hugepages

Right, let’s talk about cgroups memory limits. You’ve probably been here: you’re running a big data processing job, a leaky web app, or just a badly behaved script, and it decides it’s going to try to eat every single byte of RAM on your machine. The OS, in a desperate bid to survive, starts the OOM (Out-of-Memory) Killer, which is basically a glorified game of Russian roulette for your processes. It picks a process and shoots it dead to free up memory. Spoiler alert: it’s almost never the one you wanted it to kill.

Right, let’s talk about your RAM. Or, more accurately, let’s talk about how Linux has already laid claim to most of your RAM the second it finished booting. If you run free -h and see a paltry amount of “free” memory and start panicking, relax. You’re not about to crash. You’re witnessing one of Linux’s best performance tricks: using every spare byte of RAM it can get its hands on as a massive, intelligent cache. It’s not being greedy; it’s being brilliantly pragmatic.

Alright, let’s talk about vm.swappiness. This is the knob the kernel gives you to express your opinion on how much it should like using its swap file or partition. The key word here is opinion. You’re not giving it orders so much as strongly suggesting its drinking habits. The swappiness value isn’t a percentage of memory to use for swap, which is a common and totally understandable misconception. Instead, it’s an abstract value from 0 to 100 that controls the kernel’s aggression in moving memory pages out to disk. A higher value means the kernel will be more eager to swap stuff out to make room for more disk cache in RAM. A lower value tells the kernel to hold onto application memory in RAM for as long as it possibly can, preferring to shrink the disk cache instead.

Alright, let’s talk about huge pages. You know how your CPU’s memory management unit (MMU) has a little book of addresses called the Translation Lookaside Buffer (TLB)? Think of it as the CPU’s favorite contacts list. Every time it needs to access memory, it has to look up the virtual address in this list to find the real physical address. The problem? This list is tiny. Like, “forgets more than three items” tiny.

Right, so you’ve met the OOM Killer. It’s the kernel’s panic button, the process-sacrificing daemon that steps in when your system is gasping for its last breath of RAM. It’s not a graceful exit; it’s a chaotic, shotgun-blast approach to memory reclamation. You can’t turn it off, and you wouldn’t want to—without it, a single memory-hogging process would lock up your entire machine. But you can bribe it. You can whisper in its ear and say, “Hey, if you have to kill someone… please, not this one.” Or, conversely, “For the love of all that is holy, kill that one first.” That’s what oom_score_adj is for.

Right, let’s talk about the OOM Killer. This is the part of the Linux kernel that, when you’re desperately out of memory, stops being polite and starts getting real. It’s the digital equivalent of a bouncer at an over-capacity nightclub: its job is to pick a process to throw out so the whole system doesn’t collapse into a twitching heap. It’s brutal, often surprising, and frankly, a bit of a design admission of failure. We ran out of clever ideas, so we just pick a sucker and shoot it.

Right, let’s talk about /proc/meminfo. You’ve probably run free -h and stared at the numbers, feeling a mix of confusion and vague dread. Is my system about to fall over? Why is “free” memory so low? Is it time to panic-buy more RAM? The free command is just a pretty (well, okay) interface for the raw, glorious data in /proc/meminfo. This file is the kernel’s unvarnished, slightly chaotic confession about its current memory state. It doesn’t care about your feelings. It just reports the facts.