Read Linux Slab Pressure with slabtop Without Misreading It

Kernel memory looks tight and slabtop shows which cache is hoarding objects, though its numbers are not the same thing as physical RAM. You will take a one-off or live view of the kernel's slab caches, sort it to answer a specific question, and tell the result apart from ordinary memory usage. The examples use slabtop from procps-ng 4.0.4 on this machine. Allow about ten minutes. You need a shell; reading the kernel data normally also requires root.

Checkpoint: This guide observes kernel accounting only. It does not tune caches, stop services, drop caches, or write to /proc/slabinfo.

1. Confirm the installed command

Check the executable and version before relying on option details:

$ command -v slabtop
/usr/bin/slabtop
$ slabtop --version
slabtop from procps-ng 4.0.4

The local manual documents a default refresh interval of three seconds, plus the --once, --delay and --sort options used below. The kernel interface behind the display is /proc/slabinfo, documented separately by slabinfo(5).

2. Take one snapshot with elevated privileges

Start with a single snapshot. Use sudo if your account is allowed to read the kernel interface:

$ sudo slabtop --once
 Active / Total Objects (% used)    : 14079028 / 18298845 (76.9%)
 Active / Total Slabs (% used)      : 551347 / 551347 (100.0%)
 Active / Total Caches (% used)     : 346 / 388 (89.2%)
 Active / Total Size (% used)       : 4667391.63K / 5388549.50K (86.6%)
 Minimum / Average / Maximum Object : 0.01K / 0.29K / 10.38K

  OBJS ACTIVE  USE OBJ SIZE  SLABS OBJ/SLAB CACHE SIZE NAME

The numbers are host-specific and change while the kernel is running. The useful first question is which line or header corresponds to the problem you are investigating, not whether one percentage looks high in isolation.

On this host, running slabtop --once without sudo fails with Unable to create slabinfo structure: Permission denied. That is an access restriction, not evidence that slab accounting is disabled. Do not grant extra privileges to an unrelated user or service just to make a monitoring script work.

3. Read the header and cache columns correctly

The header reports active versus total objects, slabs, caches and slab size. The table then shows, for each cache, the total object count (OBJS), active object count, utilisation, object size, slab count, objects per slab, an estimated cache size and the cache name.

Slab objects are kernel allocations such as dentries, inode records and buffer heads. A cache can hold unused objects ready for reuse, so a large total is not automatically a leak. Look for a change over time, a cache that grows with a reproducible workload, or a mismatch with the resource symptoms you are diagnosing.

Warning: Do not report the Active / Total Size line as physical RAM consumption. The manual explicitly distinguishes slabtop's slab statistics from the Slab field in /proc/meminfo. The CACHE SIZE column is also an upper limit rather than an exact measurement, particularly when SLUB falls back to a different slab order under memory pressure.

4. Sort for the question you actually have

The default sort is by object count, represented by o. Choose another criterion before taking a snapshot:

$ sudo slabtop --once --sort=c
$ sudo slabtop --once --sort=u
$ sudo slabtop --once --sort=n

Use the long option in scripts so the intent is obvious. The sort key is one character, not a word such as size, so a typo is more likely a command-line error than a useful alternative view: check the output header and top rows after changing it.

5. Watch a changing workload briefly

For an interactive view, omit --once:

$ sudo slabtop --delay=5

This refreshes every five seconds instead of the documented three-second default. Press c, u or another sort character to change the ordering while it runs. Press the spacebar to refresh immediately and q or Q to exit.

Record the workload and sort key when comparing screens: a cache list taken during a package operation, filesystem scan or container start is not directly comparable with an idle snapshot. If you only need logs, repeat sudo slabtop --once --sort=c from a controlled shell rather than scraping a terminal animation.

6. Use slabinfo for raw interface checks

slabtop is a display tool over /proc/slabinfo. If you need the raw format for a local diagnostic, read it directly:

$ sudo head -n 4 /proc/slabinfo
slabinfo - version: 2.1
# name <active_objs> <num_objs> <objsize> <objperslab> <pagesperslab> ...

The first line versions the file format: the documented current format is 2.1, first introduced in Linux 2.6.10. The remaining records contain statistics, allocator tunables and slab data. On the default SLUB allocator the tunable fields are normally zero and the file is not writable.

Safety boundary: Do not copy an example that writes values to /proc/slabinfo. The manpage describes writable tunables for older SLAB configurations, but changing kernel allocator parameters is a separate administrative operation with host-wide consequences. Nothing in this guide needs it, and there is no general undo command that makes an experimental value harmless.

7. Investigate trends without jumping to a diagnosis

Capture repeated, comparable snapshots and keep the command, sort key, timestamp and workload beside each result. A growing cache may reflect legitimate activity, retained reusable objects, or a kernel or application issue. Correlate it with free, /proc/meminfo, service metrics and the workload before changing anything.

If a non-root monitoring account cannot read /proc/slabinfo, keep collection in a narrowly scoped privileged helper and expose only the measurements your monitoring system needs. Do not make the raw proc file broadly readable as a quick fix. If sudo slabtop --once still fails, check the command's error and the kernel's proc configuration; changing permissions or restarting services is not a first diagnostic step.

Done means