我们在128 Gb的服务器上运行debian 2.6.26-2-amd64 x86_64 GNU / Linux。 最近它的可用内存变得相当低。 看着/ proc / meminfo显示板坯正在使用88Gb，这是计算在使用的记忆过程中。
先谢谢你
> 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 你绝对肯定这是一个实际的问题：使用的内存不是不可用的内存（请参阅这免费/缓冲区/caching这个ServerFault的问题 ），想要有内存列为免费的reflection往往是错误的。
板并不是一个特定的东西，它是内核中的内存分配器之一，特别是slab让内核pipe理不是页面大小的对象（正如别处指出的/ proc / slabinfo和slabtop应该给你一些指示目前持有的是什么）。 在这里可以find更多关于slab的背景信息
如果您在Slab下方看到SReclaimable，则认为几乎所有由slab分配的内存都可以在需要时回收。 所以，是的，必要时，内存将被释放。 回收的附带成本是以cpu周期支付一些递延的簿记成本。
我不确定slab严格来说是否需要所有的内存，它会在很多情况下保留初始化的对象供以后使用（保存初始化），其中一些是各种caching，其中大部分可能是有益的（即效果的文件系统caching是巨大的）。
如果你想控制vmm的行为，请检查/ proc / sys / vm ，特别是min_slab_ratio可能是感兴趣的。 您还可以通过/ proc / slabinfo限制各个板块caching（有关详细信息，请参阅ibm developerworks文章 ）。 虽然，在开始打开vmm和slab之前：找出你真正想要完成的事情，并且对vmm进行一些研究，以及如何调整它以适应你的工作负载。 通过使用vmm调谐旋钮，可以微妙而壮观地打破系统。
使用slabtop显示内核板caching信息：
slabtop
另请参阅“vmstat -m”：
vmstat -m
并看看/ proc / slabinfo：
cat /proc/slabinfo
将caching放到空闲的内存中
sync; echo 3 > /proc/sys/vm/drop_caches