Read Linux Slab Cache Statistics from /proc/slabinfo

You will learn how to inspect the kernel's slab caches, identify the largest object caches, and relate the result to the slab total in /proc/meminfo. Allow about ten minutes. You need a Linux shell and, on the systems covered by the installed manpage, root access to read /proc/slabinfo.

The local reference is Linux man-pages 6.7, package version 6.7-2. Its short proc_slabinfo(5) page points to slabinfo(5) for the file format. The file is diagnostic input. Do not write to it while following this guide.

1. Check the proc file before interpreting it

First confirm that the proc filesystem exposes the file and that your account can read it. This check is ordinary and does not change the system:

$ stat /proc/slabinfo
$ test -r /proc/slabinfo && echo readable || echo "not readable as this user"

On this host the installed documentation says that only root can read the file. If the second command reports that it is not readable, repeat the read with sudo rather than changing procfs permissions:

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

Checkpoint: you should see a version line followed by a column heading and cache records. If stat fails, check that /proc is mounted. If the read is denied even through your approved administrative path, stop there; this is an access boundary, not a parsing problem.

2. Read one cache record

Each record begins with a cache name and then presents statistics, tunables and slab data. A representative record from the manpage has this shape:

sigqueue      100  100  160  25  1 : tunables  0  0  0 : slabdata  4  4  0

The first five numbers after the name are active_objs, num_objs, objsize, objperslab and pagesperslab. Active objects are currently in use. The total object count also includes unused allocated objects. Object size is in bytes. The final two of these five values describe how many objects and pages make up a slab.

After :, the three tunable fields are limit, batchcount and sharedfactor. With the default SLUB allocator, the file is not writable and these values are shown as zero. That zero is not a promise that the cache is empty. It is a consequence of the allocator format.

The slabdata values are active_slabs, nums_slabs and sharedavail. The manpage leaves sharedavail undocumented, so do not assign your own meaning to it.

3. Find caches worth investigating

For a quick view, filter the records by a cache name you already suspect. Quote the pattern if it came from another command:

$ sudo awk '$1 == "dentry" || $1 == "inode_cache" {print}' /proc/slabinfo

Those names are examples, not guaranteed entries. A kernel, workload or allocator configuration can expose different caches. An empty result is useful: it means that exact name is not present, not that slab allocation has stopped.

For a readable live display, use slabtop, which reads the same proc data and sorts the cache list:

$ sudo slabtop --once
 Active / Total Objects (% used)    : 123456 / 234567 (52.6%)
 Active / Total Slabs (% used)      : ...
 CacheSize: ...
 ...

The exact numbers and rows vary continuously, so treat the output above as a layout example. --once prints one snapshot and exits. Without it, slabtop refreshes every three seconds and you leave it with q. Its cache-size display is an upper limit for the selected slab, not a direct measurement of physical memory.

4. Compare the cache view with total slab memory

Use /proc/meminfo to see the kernel's slab total in the Slab field:

$ awk '$1 == "Slab:" {print}' /proc/meminfo
Slab:             123456 kB

This is a second, independent checkpoint. The manpage describes Slab as the total amount of memory allocated to the SLAB or SLUB cache. Do not expect a simple sum of the visible object sizes to equal it: alignment, metadata, unused objects and pages that contain even one live object all affect memory use.

Take two snapshots if you are investigating a suspected growth trend:

$ sudo slabtop --once > /tmp/slabtop-before.txt
$ sleep 10
$ sudo slabtop --once > /tmp/slabtop-after.txt
$ diff -u /tmp/slabtop-before.txt /tmp/slabtop-after.txt

The files under /tmp are disposable observations. Remove them when finished with rm -- /tmp/slabtop-before.txt /tmp/slabtop-after.txt, or leave them for the normal temporary-file cleanup. This does not alter the kernel caches.

5. Respect the write boundary

Do not copy a command that redirects text into /proc/slabinfo. The older SLAB allocator had tunables that could be changed with a specially formatted write, but the installed manpage says the default SLUB allocator does not make the file writable. Only root can write it when the kernel has been configured with CONFIG_SLAB.

Writing a guessed cache name or invalid values is not a safe test. The documented constraints are positive limit, positive batchcount no greater than limit, and non-negative sharedfactor; invalid settings are left unchanged, but that is not a substitute for a maintenance plan. This guide makes no configuration change, so there is no undo action to perform.

6. Handle format and version traps

Read the first line before writing a parser. The current format named by the manpage is version 2.1, first introduced in Linux 2.6.10. Older kernels exposed earlier layouts, and kernels built with CONFIG_DEBUG_SLAB can add statistics fields and the word (statistics) to the header. A script that assumes fixed field positions can therefore misread a different kernel.

For automation, record the version string, preserve the cache name as a field, and reject an unfamiliar layout rather than silently producing misleading totals. If you only need a human diagnosis, slabtop is less brittle than hand-written column arithmetic.