How To Improve Memory

Why Your Server is Slow and It's Not the CPU

I've spent years walking into rooms where someone complains their application is slow, and ten minutes later we're looking at a server whose memory is thrashing. The fix is rarely as simple as adding RAM, but it's also rarely as dramatic as replacing hardware. The actual problem usually sits in how the OS is using what you already have. The first thing I check is whether you're actually dealing with memory pressure or if something else is masquerading as a memory problem. A machine can be using 90% of its RAM and still have plenty of headroom because the kernel is using free memory for disk caching. But if swappiness is set to the default of 60 on a modern server, that cache gets evicted aggressively and performance tanks under load. Setting it to 10 or even 5 keeps useful pages in RAM longer. The command is straightforward: sysctl vm.swappiness=10 makes it stick across reboots if you add it to /etc/sysctl.conf. Another thing people routinely get wrong is how they monitor memory. Most dashboards show "available" memory and assume high usage means a problem. Check the actual reclaimable space and the pressure stalls instead. Tools like smem give you per-process memory breakdowns that ps alone won't show you. The PSS and USS numbers from smem reveal which processes are actually competing for physical pages versus just holding shared libraries. I had a situation once where a Java application was consuming 40GB of reported RSS, but the USS was only 200MB because nearly everything was shared with other containers on the same host. The real issue was cgroup misconfiguration, not a memory leak.

Understanding What Actually Happens When Memory Runs Out

When the kernel can't allocate more pages, it starts killing processes. The OOM killer picks targets based on a score calculated from memory usage, oom_score_adj values, and how much work the process is doing. You can influence this by setting oom_score_adj for critical services. Writing -1000 to /proc//oom_score_adj makes the kernel skip that process entirely during OOM conditions. It's not a silver bullet because if the system is truly out of memory, nothing helps, but it prevents your database from dying while a background worker gets nuked instead. The counter-intuitive part most people miss is that sometimes having more free memory actively hurts performance. The page allocator spends time compaction and reclaiming before it can satisfy large allocation requests. Transparent huge pages were supposed to help with this, but in practice they cause latency spikes under memory pressure because the compaction thread stalls the allocating process. I've seen response times jump from single-digit milliseconds to over 200ms on PostgreSQL clusters that had THP enabled. Disabling it with echo never > /sys/kernel/mm/transparent_hugepage/enabled and putting that in rc.local or a systemd unit cut those spikes to almost nothing.

NUMA Topology Matters More Than You Think

If you're running on multi-socket hardware, the distance between a CPU and its local memory matters. A process allocated on CPU 0 that accesses memory attached to node 1 experiences higher latency. The default behavior lets the kernel decide placement, and it usually does a decent job, but for latency-sensitive workloads this is where you start seeing inconsistent performance between runs. numactl lets you pin a process to specific nodes. Running a service with numactl --cpunodebind=0 --membind=0 keeps everything on the same socket and eliminates cross-node traffic. This typically reduces tail latency by 10 to 30 percent depending on the workload. I ran into a case where a high-frequency trading application was getting sporadic latency spikes that correlated perfectly with garbage collection cycles on the remote NUMA node. The Java heap was growing past the local memory capacity, forcing allocations across the QPI link. Binding the JVM to the local node and tuning the heap size to stay within local memory resolved it completely. The fix wasn't faster hardware, just tighter binding.

Application-Level Memory Issues

Memory leaks in applications follow predictable patterns. In managed runtimes like JVM or Go, objects that stay reachable longer than necessary create gradual growth until you hit your limit. The telltale sign is a steady upward slope on a memory graph that never comes back down. In C or C++ applications, the pattern is different: you'll see sudden jumps in RSS followed by fragmentation, and tools like Valgrind or jemalloc's prof facility will show you exactly where allocations are escaping cleanup. The workaround is rarely to rewrite the allocator. It's usually to identify the allocation path and add a bounded pool or fix a missing free in a code path that only triggers under specific conditions. For containerized environments, memory limits need to be set carefully. If you set a cgroup memory limit too close to what the application actually needs, the kernel will kill the container before the application's own OOM handler fires. The rule of thumb is to leave about 10 to 15 percent overhead beyond the application's working set. You can measure the working set with smem or by watching the RSS over a full production cycle, not just a stress test. Stress tests inflate working sets because they exercise code paths that normal traffic never touches.

When Adding RAM Is Actually the Right Answer

Sometimes the problem is just not enough memory. This is most obvious when you see continuous swap activity, high iowait from swap I/O, and the system struggling to serve requests. The sweet spot for memory depends heavily on your workload. A caching database like Redis benefits from fitting the entire dataset in RAM with no swap. A batch processing job that works with large in-memory structures needs enough to hold the data plus some breathing room. A web server doing mostly I/O-bound work with small process footprints needs far less per connection. One hard limit to understand is that the Linux kernel's buddy allocator fragments over time. Long-running systems can develop external fragmentation even with plenty of free pages. Rebooting periodically, or using the kernel's compaction feature through echo 1 > /proc/sys/vm/compact_memory, can reclaim fragmented memory. I've seen servers that had been up for six months show noticeable improvement after a scheduled weekly compaction run, especially under allocation-heavy workloads.

The Tradeoffs You Can't Ignore

Tuning memory behavior always involves tradeoffs. Aggressive cache retention with low swappiness improves performance under moderate load but can starve the system when an unexpected memory spike occurs. NUMA binding improves latency but reduces scheduling flexibility and can lead to suboptimal CPU utilization if your workload isn't evenly distributed across cores. Disabling transparent huge pages reduces latency spikes but may lower throughput for certain sequential access patterns. The practical approach is to baseline your current performance, make one change at a time, and measure the delta. A tool like wrk or ab for web workloads, pgbench for databases, or your own benchmark suite gives you the data you need. Without baseline numbers, you're just guessing whether a change helped or hurt. I've seen people spend hours on memory tuning without ever measuring what changed because they had no reference point. If your application has a genuine memory leak, no amount of OS-level tuning will fix it. The memory usage will keep climbing until the OOM killer intervenes. In that case, the right move is to identify and patch the leak, or at minimum set up a restart schedule that limits the blast radius. A daily restart of a batch worker that leaks 2GB is far less painful than an unpredictable OOM kill during peak hours.

Download a monitoring setup script that checks swappiness, THP status, NUMA binding, and cgroup limits in one pass. It's available from the standard repository and takes about two minutes to run. The output tells you which of these settings are currently deviating from recommended values for your workload type. Most servers I check have at least two of these misconfigured.