8

We run a debian 2.6.26-2-amd64 x86_64 GNU/Linux on a server with 128 Gb. Recently it our available memory became rather low. Looking at the /proc/meminfo showed that the Slab was using 88Gb, which is counted in the used memory off course.

  1. Is this a problem? I suspect that memory will be freed when necessary, but I don't know if that could have unwanted side effects.
  2. Why would Slab need that much memory? Is there a clear cause for that?
  3. can we avoid this to happen in the future?
  4. How can we free this memory?

thank you in advance

> cat /proc/meminfo
MemTotal:     132304500 kB
MemFree:      26669388 kB
Buffers:        237504 kB
Cached:       11881136 kB
SwapCached:         48 kB
Active:        5244640 kB
Inactive:     11714308 kB
SwapTotal:     5751228 kB
SwapFree:      5750436 kB
Dirty:              24 kB
Writeback:           0 kB
AnonPages:     4840256 kB
Mapped:         163968 kB
Slab:         88314840 kB
SReclaimable: 88275644 kB
SUnreclaim:      39196 kB
PageTables:      80852 kB
NFS_Unstable:        0 kB
Bounce:              0 kB
WritebackTmp:        0 kB
CommitLimit:  71903476 kB
Committed_AS:  6818332 kB
VmallocTotal: 34359738367 kB
VmallocUsed:    505724 kB
VmallocChunk: 34359231963 kB
Joris Meys
  • 185
  • 1
  • 1
  • 7

2 Answers2

11

Use slabtop display kernel slab cache information:

slabtop

Aslo see "vmstat -m":

vmstat  -m

and look /proc/slabinfo:

cat /proc/slabinfo

Drop cache to free memory

sync; echo 3 > /proc/sys/vm/drop_caches
ooshro
  • 10,874
  • 1
  • 31
  • 31
  • thx for the commands, they make life indeed a bit easier. – Joris Meys Feb 27 '11 at 01:04
  • Careful with drop_caches, some applications using memory might not react well to having their "in use" memory dropped. Which number is written depends on how aggressive you want caches dropped, start with 1 and continue to 3 as needed. Also helps to run "sync" beforehand. – user2280032 Aug 11 '21 at 16:18
5

Are you absolutely certain this is an actual problem: used RAM is not the same as unavailable ram (See i.e. this ServerFault question on free/buffers/cache), the reflex of wanting to have memory listed as free is often wrong.

Slab isn't one specific thing, it's one of the memory allocators within the kernel, in particular slab lets the kernel manage objects which aren't page-sized (as pointed out elsewhere /proc/slabinfo and slabtop should give you some indication of what it's currently holding on to). Some more background on slab can be found here

If you see the SReclaimable below Slab, it's of the opinion that almost all the memory allocated by slab can be reclaimed when/if needed. So, yes, memory will be freed when necessary. The incidental cost of reclaiming are paying some deferred bookkeeping-costs in cpu-cycles.

I'm not sure if slab strictly speaking need all that memory, it'll in a lot of cases retain initialized objects for later use (saving initialization), some of it are various caches, most of this is are probably beneficial (I.e. effects of filesystem-caches are immense).

If you want to control the behavior of the vmm, check out /proc/sys/vm, in particular min_slab_ratio might be of interest. You can also limit individual slab-caches through /proc/slabinfo (see the ibm developerworks article for details). Although, before you start turning on the vmm and slab: Figure out what you actually want to accomplish, and do some research on the vmm and how it can be tuned to fit your workload(s). It's quite possible to break your system both subtly and spectacularly by playing around with vmm tuning-knobs.

Community
  • 1
Kjetil Joergensen
  • 5,854
  • 1
  • 26
  • 20