Memory pressure often causes problems well before it shows up as an obvious outage — a host that's slowly running low on memory tends to get progressively slower, not suddenly unreachable, which makes it one of the more valuable metrics to watch trends on rather than just a single snapshot.
What's measured
- Used, free, and available memory
- Swap usage, on hosts that have swap configured — any sustained swap activity is usually a sign that physical memory is undersized for the workload
- Buffer/cache memory, on Linux hosts, which is normal and reclaimable, and shouldn't be counted the same way as memory actually in use by applications
Reading memory correctly
On most operating systems, "used" memory alone can be misleading, since the OS deliberately uses spare memory for disk caching to improve performance — that cache is released instantly if an application needs it. What actually matters for health is available memory (what's genuinely free for use) and swap activity, not raw "used" percentage.
Setting thresholds
Set thresholds against available memory or swap usage rather than raw used-memory percentage, to avoid false alarms from healthy cache usage. A Warning threshold on rising swap activity is often more useful than any fixed memory percentage.
Spotting a leak versus normal load
Normal memory usage tends to rise and fall with application load throughout the day. A leak looks different: a steady, one-directional climb that doesn't drop back down even during quiet periods, and eventually forces the host into swap or triggers an out-of-memory condition. Viewing a memory graph over several days (rather than hours) — see Performance Metrics for how graph timespans work — is usually the fastest way to tell the two apart.