Memory loss after long uptime

[Konstantin Svist]

On 04/27/2012 10:02 PM, Chris Adams wrote:
> Once upon a time, Rick Stevens<ricks at alldigital.com>  said:
>> You might try having a look at the output of ipcs after stopping MySQL
>> and see if your missing memory is in one or more of the shm segments.
>> If so, you can reclaim it by using "ipcrm -m<shmid>". You'd be
>> surprised at how many programs don't release IPC resources--especially
>> if they are rudely terminated (e.g. SIGSEGV or SIGKILL).
> Are you sure?  I've been running MySQL for a long time, and I don't
> remember it ever using SysV IPC.  I certainly don't see it using that
> now, even on an old version I still have running (much older than the
> OP's F14).
>
> To the OP: if you think you are seeing RAM in use that isn't reflected
> when comparing the output of "free" to "ps"/"top" process usage, it
> could be in other kernel buffers.  Check out "slabtop" (has to run as
> root); there are other kernel caches that "free" doesn't know about,
> especially the dentry and inode caches.  These will show up as just more
> kernel RAM in use, but really they are caches that should be discarded
> as needed (just like the old buffers/cache lines in "free").


Here's slabtop from one machine that's using too much RAM:

  Active / Total Objects (% used)    : 8516783 / 8967394 (95.0%)
  Active / Total Slabs (% used)      : 270701 / 270701 (100.0%)
  Active / Total Caches (% used)     : 68 / 101 (67.3%)
  Active / Total Size (% used)       : 5113995.32K / 5341810.93K (95.7%)
  Minimum / Average / Maximum Object : 0.01K / 0.59K / 8.00K

   OBJS ACTIVE  USE OBJ SIZE  SLABS OBJ/SLAB CACHE SIZE NAME
3836868 3691157  96%    1.00K 119903       32   3836896K kmalloc-1024
3624368 3573469  98%    0.25K 113262       32    906096K kmalloc-256
570560 553390  96%    0.50K  17830       32    285280K kmalloc-512
197526 196494  99%    0.55K   3468       57    110976K radix_tree_node
140992 114638  81%    0.12K   4406       32     17624K kmalloc-128
113856  29876  26%    0.06K   1779       64      7116K kmalloc-64
  40448  40445  99%    0.01K     79      512       316K kmalloc-8
  35904  35485  98%    0.08K    704       51      2816K sysfs_dir_cache
  32724  26778  81%    1.69K   1818       18     58176K TCP
  29190  16929  57%    0.19K    695       42      5560K dentry
  26112  16386  62%    0.02K    102      256       408K ext4_io_page
...


Looks like the kmalloc-##s are taking up most of the space.
Question is, what (if anything) can be done about this on a running 
system? Any way to reclaim that memory?