{"id":3293,"date":"2026-09-30T10:10:17","date_gmt":"2026-09-30T10:10:17","guid":{"rendered":"https:\/\/siteharbour.com\/blog\/?p=3293"},"modified":"2026-09-30T10:10:17","modified_gmt":"2026-09-30T10:10:17","slug":"diagnose-memory-pressure-linux","status":"publish","type":"post","link":"https:\/\/siteharbour.com\/blog\/diagnose-memory-pressure-linux\/","title":{"rendered":"How to Diagnose Memory Pressure on Linux"},"content":{"rendered":"

A Linux server is under memory pressure when processes are actually stalling to get memory, or the kernel is swapping heavily or killing processes, not when the “free” column looks low. To tell the difference, check four things in order: the available<\/code> figure in free<\/code>, the swap-in and swap-out columns in vmstat<\/code>, the Pressure Stall Information (PSI) files in \/proc\/pressure<\/code>, and the kernel log for out-of-memory kills. This guide shows each check with real output from a 1 GB production server, and what each result means.<\/p>\n

It pairs with the guides on optimizing WordPress on a 1 GB server<\/a>, sizing PHP-FPM workers<\/a> and tuning MySQL and MariaDB<\/a>: those articles tell you how to change memory use, and this one tells you whether you have a problem at all. The examples use Ubuntu 24.04.<\/p>\n

Why low free memory is normal on Linux<\/h2>\n

Linux uses spare RAM as a cache for files it has read recently. That cache is not wasted: it makes the server faster, and the kernel gives it back the moment a program needs the memory. A healthy server that has been running for a while therefore shows almost no truly free memory. The number that matters is available<\/code>, the kernel’s estimate of how much memory could be given to new programs without swapping.<\/p>\n

\n

Do not “free” memory by dropping caches.<\/strong> Commands that write to \/proc\/sys\/vm\/drop_caches<\/code> throw away the cache you just benefited from, and the server is slower until it warms up again. They fix nothing.<\/p>\n<\/div>\n

Step 1: Read free and meminfo correctly<\/h2>\n

Start with the human-readable summary and the raw counters behind it:<\/p>\n

free -h\ngrep -E 'MemTotal|MemAvailable|SwapTotal|SwapFree' \/proc\/meminfo<\/code><\/pre>\n
Here is what they printed on a 1 GB server that runs a Laravel application and a WordPress blog:<\/p>\n
               total        used        free      shared  buff\/cache   available\nMem:           911Mi       605Mi       100Mi        67Mi       443Mi       305Mi\nSwap:          2.0Gi       130Mi       1.9Gi\n\nMemTotal:         933332 kB\nMemAvailable:     313200 kB\nSwapTotal:       2097144 kB\nSwapFree:        1963120 kB<\/code><\/pre>\n
Only 100 Mi is free, which looks alarming, but 443 Mi is cache and 305 Mi is available, about a third of all RAM. As a rough guide, available memory that stays below about 10 percent of the total on a small server deserves attention. That is a starting point for investigation, not a law, because what matters is whether anything is actually stalling, which the next steps check.<\/p>\n
The shared<\/code> column (67 Mi here) covers memory used by tmpfs filesystems and shared memory segments, such as a PHP OPcache. It is normally small.<\/p>\n
Step 2: Watch swap activity with vmstat<\/h2>\n
Swap in use is not the same as swapping. The kernel moves pages that nothing has touched for a while out to swap so the RAM can serve as cache, and those pages can sit there indefinitely. What indicates trouble is continuous traffic in and out of swap. Sample it with vmstat<\/code>, one line per second:<\/p>\n
vmstat 1 5<\/code><\/pre>\n
procs -----------memory---------- ---swap-- -----io---- -system-- -------cpu-------\n r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st gu\n 0  0 134024 103352  44076 410328    0    0     0     0  369  554  0  1 99  0  0  0\n 0  0 134024 103352  44076 410328    0    0     0     0  262  497  1  1 99  0  0  0<\/code><\/pre>\n
Ignore the first line of real output, because it shows averages since boot. The columns to watch are:<\/p>\n\n\n\n\n\n\n\n\n
Column<\/th>\nMeaning<\/th>\nWorry when<\/th>\n<\/tr>\n<\/thead>\n
si<\/code> \/ so<\/code><\/td>\nSwap-in and swap-out, in KB per second<\/td>\nConsistently nonzero under normal load<\/td>\n<\/tr>\n
b<\/code><\/td>\nProcesses blocked, usually waiting for disk<\/td>\nPersistently above zero<\/td>\n<\/tr>\n
wa<\/code><\/td>\nCPU time waiting for I\/O<\/td>\nPersistently high, often together with swapping<\/td>\n<\/tr>\n
st<\/code><\/td>\nCPU time stolen by the hypervisor<\/td>\nConsistently above a few percent on a virtual server<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n
On this server swpd<\/code> is 134,024 KB (about 131 MiB) but si<\/code> and so<\/code> are zero on every line, and the CPU is 99 to 100 percent idle. Those pages are simply parked. At an earlier snapshot the same server had about 71 MiB in swap, so the figure creeps up over time without any performance effect. Remember that this is a quiet moment, so repeat the sample while the site is busy.<\/p>\n
The swappiness<\/code> setting controls how eagerly the kernel swaps. This server uses a low value:<\/p>\n
cat \/proc\/sys\/vm\/swappiness\n10<\/code><\/pre>\n
Step 3: Read Pressure Stall Information (PSI)<\/h2>\n
PSI is the most direct measurement of memory pressure. Instead of inferring trouble from counters, the kernel records how much time processes actually spent waiting. Read all three resources:<\/p>\n
cat \/proc\/pressure\/memory \/proc\/pressure\/cpu \/proc\/pressure\/io<\/code><\/pre>\n
Each file has a some<\/code> line and a full<\/code> line:<\/p>\n