Memory metrics
Memory charts show what RAM is being used for, whether the host is swapping, and whether tasks waited for memory. Used percent can look comfortable while PSI and major faults say the kernel is reclaiming hard. Swap traffic and disk-backed page reads sit in their own Paging group on the console because they mean the same thing — you are out of RAM.
Overview tile
Memory used is a derived percent: used bytes over capacity. Used excludes reclaimable file cache, so it is what the kernel could not hand to a new allocation without evicting something. The tile is the latest value of derived.memoryUsedPercent.
Memory breakdown
| Series | Wire name | What it is |
|---|---|---|
| Memory used | host.memory.usedBytes | RAM genuinely in use — process heap, kernel, everything the kernel could not reclaim |
| Cached files | host.memory.cachedFilesBytes | Page cache — file data the kernel kept because the RAM was idle |
Used is the best single gauge of "can this host take more work". Cached is not a problem: Linux uses idle memory as cache on purpose and drops it under pressure. A rising used line is the warning; a large cached number by itself is not. Used plus cached leaving little of the total is a host that has stopped caching — the next step is pressure.
Both series are stored as bytes, not as a percentage of a capacity, so a RAM upgrade does not rewrite last week's history — each bucket is divided by the capacity of the topology generation it was sampled under.
Memory used
derived.memoryUsedPercent — used as a percent of capacity, computed on the control plane from used bytes and the known total. Area chart, 0–100%.
Treat the last 10–15% as the danger band on a host that also runs databases or caches — those want the cache. Pair a high used % with PSI before assuming you must add RAM: a cache-heavy host can sit at 90% used with zero pressure.
Swap used
host.memory.swapUsedBytes — bytes currently on swap. Zero is legitimate when swap is off or unused; the series still plots.
Some swap on a long-lived host is common (idle pages pushed out). A climbing line together with swap-in traffic and memory PSI means the host is actively paging, not just holding old pages on disk.
Swap used %
derived.swapUsedPercent — swap used as a percent of swap capacity. Hidden-looking zeros still mean “no swap in use,” not “swap is missing.” If the host has no swap at all, used bytes stay at 0 and this percent stays at 0.
Memory pressure (PSI)
PSI for RAM — share of this sample's wall clock that tasks spent waiting on memory, not how full RAM is. Used % can sit high with this chart at zero (a healthy cache). Two series:
| Series | Wire name | What it is |
|---|---|---|
| Some | host.memory.pressureSomePercent | At least one task waited for memory — reclaim, compaction, or swap |
| Full | host.memory.pressureFullPercent | Every non-idle task waited. The machine stalled |
Some is contention. Full above zero for more than a spike is thrashing: nothing useful ran because everything was waiting on memory. That is more serious than a high used %.
| What you see | Typical reading |
|---|---|
| Both near 0% | Allocations are being satisfied without stalls |
| Some rising, Full still ~0 | Reclaim is working but costing latency — check major faults and swap I/O |
| Full leaving zero | Severe. Shed load, add RAM, or find the leak. The host was not doing application work during those samples |
The chart hides when /proc/pressure/memory is missing.
Swap I/O
| Series | Wire name | What it is |
|---|---|---|
| Swap in | host.memory.swapInBytesPerSecond | Pages read back from swap into RAM |
| Swap out | host.memory.swapOutBytesPerSecond | Pages written out to swap |
Swap-out without swap-in is the kernel parking idle pages — often harmless. Swap-in is the expensive direction: a process needed those pages and waited on disk. Swap-in plus memory Full PSI is the classic “this host is too small for its working set.”
The chart hides when both series stay empty.
Major page faults
host.memory.majorPageFaultsPerSecond — faults that required a disk read (not the cheap minor faults satisfied from RAM).
A burst at process start is normal (demand paging). A sustained rate, especially with swap-in, means the working set does not fit. Pair with I/O PSI if the disk is the one paying for it.
Memory detail
These charts are the memory half of the host diagnostics row (host.diagnostics), reported by every Linux host at every license tier — S1 included — and on self-hosted. There is nothing to enable.
They answer a different question from the Memory group above. Used % and PSI tell you whether the host is short of RAM. Memory detail tells you what that RAM is made of and whether the kernel is working to free some. You open this group when used looks wrong (high used, tiny processes), when a flush or leak is suspected, or when memory PSI is up and you want to see reclaim happening.
The numbers come from /proc/meminfo (bytes in RAM right now) and /proc/vmstat (how hard the kernel scanned or compacted in this sample). Schema v6 dropped seven older detail fields — page tables, kernel stack, the commit limit, and the four active/inactive splits — so this row fits next to CPU diagnostics. The seven charts below are what remains.
Free & cached memory
How RAM is split right now, before you look at kernel caches and writeback.
| Series | Wire name | What it is |
|---|---|---|
| Free | diagnostics.memoryFreeBytes | Pages sitting unused. Linux treats idle RAM as wasted, so low Free is normal on a machine that has been up a while |
| Cached | diagnostics.cachedBytes | File data kept in RAM because nothing else needed the pages. The kernel can drop this under pressure |
| Anonymous | diagnostics.anonPagesBytes | Process heap, stack, and similar — not backed by a file. This is the line that becomes swap, and the usual leak signature if it only goes up |
Cached here is not the same series as Cached files on the overview. Overview Cached files is the reclaimable file-cache total (page cache + buffers + reclaimable slab, minus shared memory). This Cached line is the kernel's raw Cached counter, which still includes some tmpfs / shared pages. They will not match; that is expected.
| What you see | Typical reading |
|---|---|
| Low Free, large Cached, steady Anonymous | Healthy — Linux spent idle RAM on cache |
| Anonymous climbing, Cached shrinking | Processes are eating the working set. Pair with used % and PSI |
| Anonymous climbing without bound | Leak (or a working set that does not fit). Check the process, not Free |
| High Free and low Cached on a long-lived host | Cache was flushed (drop_caches, a huge file read that aged out) or the box is idle after boot |
Slab memory
Kernel object caches — dentries, inodes, network buffers — not your application heap.
| Series | Wire name | What it is |
|---|---|---|
| Reclaimable | diagnostics.slabReclaimableBytes | Kernel caches it can drop (directory and inode caches, and similar). Same idea as file cache: useful until RAM is needed |
| Unreclaimable | diagnostics.slabUnreclaimableBytes | Kernel objects that stay until their owner is gone (sockets, file structs). Does not shrink just because a user process exits |
| What you see | Typical reading |
|---|---|
| Modest reclaimable, flat unreclaimable | Normal |
| Reclaimable large, PSI still ~0 | Harmless — extra kernel cache |
| Unreclaimable climbing for hours | Lots of kernel objects: connections, open files, or a leak in a kernel path. This is RAM you cannot get back without closing those owners |
Dirty & writeback pages
File pages waiting to hit disk, then the ones the kernel is writing right now.
| Series | Wire name | What it is |
|---|---|---|
| Dirty | diagnostics.dirtyBytes | File pages modified in RAM, not yet written |
| Writeback | diagnostics.writebackBytes | Pages in flight to disk this instant |
A quiet host sits near zero on both. Writers (databases, logs, backups, unpacking a tarball) dirty pages; the kernel later writes them.
| What you see | Typical reading |
|---|---|
| Small Dirty, Writeback ~0 | Normal |
| Dirty spike, then Writeback, then both fall | A flush — backup, log rotate, a write burst. Expected |
| Dirty staying large, Writeback stuck, I/O PSI up | The disk cannot keep up. Look at disk latency and block devices |
Shared memory
diagnostics.shmemBytes — RAM used as shared pages: tmpfs (/dev/shm, a RAM disk), POSIX shared memory, and some container overlay backing.
It counts toward used memory but does not show up as any one process's RSS, which is why used can grow while every process still looks small.
| What you see | Typical reading |
|---|---|
| Small and flat | Normal |
| Climbing with used, processes still small | A tmpfs or /dev/shm cache is filling — a build directory on RAM, a session store, Docker overlay pressure — not a userspace leak |
| Jump then flat | Something mounted a RAM disk or allocated a shared segment and is holding it |
Committed memory
diagnostics.committedAsBytes — virtual memory the kernel has promised to processes (Linux Committed_AS), not how much is sitting in RAM this second.
Linux overcommits: a process can mmap more than the machine has, and only pay when it touches those pages. JVMs, databases, and language runtimes do this on purpose. Committed can therefore sit above physical RAM while used % still looks fine.
| What you see | Typical reading |
|---|---|
| Near Anonymous, well under RAM | Conservative allocators — nothing to do |
| Above RAM, used % still comfortable | Overcommit. Fine until the promises are cashed in |
| Climbing past RAM plus swap | The shape that ends in an OOM kill even while used % still looks fine. The kernel promised more than it can ever place |
Page reclaim
How hard the kernel scanned page lists this sample to free RAM. These are rates (/s), not bytes in RAM.
| Series | Wire name | What it is |
|---|---|---|
| Direct scan | diagnostics.pageScanDirectPerSecond | A process needed a page now and had to scan itself. That process stalls until reclaim finishes |
| kswapd scan | diagnostics.pageScanKswapdPerSecond | Background reclaim (kswapd). The kernel is topping up Free so the next allocation does not stall. Healthier than direct scan |
Zero on both is a host that is not under memory pressure. kswapd doing a little work is the kernel keeping a cushion. Direct scan is the expensive path.
| What you see | Typical reading |
|---|---|
| Both ~0 | No reclaim — RAM is keeping up |
| kswapd only, small | Background housekeeping. Fine |
| Direct scan rising with memory Some PSI | The kernel is stealing time from applications to free RAM. Shed load or add RAM |
| Direct scan high, Full PSI leaving zero | Thrashing. Pair with swap I/O and major faults |
Compaction stalls
diagnostics.compactionStallsPerSecond — times this sample the kernel paused a process to shuffle fragmented pages into a contiguous block (needed for huge pages or a large contiguous allocation).
This is not “how fragmented is RAM” as a gauge. It is how often fragmentation cost a wait. Occasional spikes (a database starting, a huge-page pool filling) are normal. A sustained rate means fragmentation is adding latency even if used % looks fine.
| What you see | Typical reading |
|---|---|
| 0/s | Nothing waited on compaction |
| Brief spikes | A large allocation or huge-page setup. Fine |
| Sustained, especially with Direct scan | Fragmentation is in the way. Memory PSI and reclaim will usually be up too |
Related
Last updated on