问一个关于slabinfo的问题

chenrvmldd 发表于 2011-04-12 09:58

最近在研究Linux2.4.25的内核发现一个奇怪的问题：在我的板子上我发现内核初始化后占用的内存非常大：
/ # free
               total       used       free    shared    buffers
Mem:    13964    12404       1560          0          0
Swap:          0          0          0
Total:    13964    12404       1560
/ # cat /proc/meminfo
   total: used: free:shared: buffers:cached:
Mem:14299136 127098881589248    0    01941504
Swap:    0    0    0
MemTotal:    13964 kB
MemFree:       1552 kB
MemShared:       0 kB
Buffers:          0 kB
Cached:       1896 kB
SwapCached:       0 kB
Active:          428 kB
Inactive:       1716 kB
HighTotal:       0 kB
HighFree:          0 kB
LowTotal:    13964 kB
LowFree:       1552 kB
SwapTotal:       0 kB
SwapFree:          0 kB
从上面内存打印出的信息，可以看出剩余的内存只有1560K，剩余的内存太小了，后来经过仔细的分析，我发现我的系统中slab占用内存太多了：
/ # cat /proc/slabinfo
slabinfo - version: 1.1
kmem_cache          65 72 108 2 2 1
tcp_tw_bucket       0    0 96 0 0 1
tcp_bind_bucket    2 113 32 1 1 1
tcp_open_request    0    0 64 0 0 1
inet_peer_cache    0    0 64 0 0 1
ip_fib_hash          5 113 32 1 1 1
ip_dst_cache       0    0 160 0 0 1
arp_cache          0    0 96 0 0 1
blkdev_requests    512 520 96 13 13 1
jffs2_inode_cache 458 580 24 4 4 1
jffs2_node_frag    591 1890 28 5 15 1
jffs2_raw_node_ref 2928 3030 16 15 15 1
jffs2_tmp_dnode    0 1518 12 0 6 1
jffs2_raw_inode    0 56 68 0 1 1
jffs2_raw_dirent    0    0 40 0 0 1
jffs2_full_dnode 622 2020 16 4 10 1
nfs_write_data       0    0 384 0 0 1
nfs_read_data       0    0 352 0 0 1
nfs_page             0    0 96 0 0 1
dnotify_cache       0    0 20 0 0 1
file_lock_cache    0    0 96 0 0 1
fasync_cache       0    0 16 0 0 1
uid_cache          0    0 32 0 0 1
skbuff_head_cache 2048 2064 160 86 86 1
sock                6 10 768 2 2 1
sigqueue             0 29 132 0 1 1
kiobuf             0    0 64 0 0 1
cdev_cache          4 113 32 1 1 1
bdev_cache          2 59 64 1 1 1
mnt_cache          9 59 64 1 1 1
inode_cache       64 64 480 8 8 1
dentry_cache       82 90 128 3 3 1
filp                12 30 128 1 1 1
names_cache          0    2 4096 0 2 1
buffer_head          0    0 96 0 0 1
mm_struct          5 30 128 1 1 1
vm_area_struct    21 40 96 1 1 1
fs_cache             4 113 32 1 1 1
files_cache          5    9 416 1 1 1
signal_act          8    9 1312 3 3 1
size-131072(DMA)    0    0 131072 0 0 32
size-131072          0    1 131072 0 1 32
size-65536(DMA)    0    065536 0 0 16
size-65536          3    365536 3 3 16
size-32768(DMA)    0    032768 0 0 8
size-32768          0    032768 0 0 8
size-16384(DMA)    0    016384 0 0 4
size-16384          0    016384 0 0 4
size-8192(DMA)       0    0 8192 0 0 2
size-8192          2    2 8192 2 2 2
size-4096(DMA)       0    0 4096 0 0 1
size-4096       2055 2055 4096 2055 2055 1
size-2048(DMA)       0    0 2048 0 0 1
size-2048          7    8 2048 4 4 1
size-1024(DMA)       0    0 1024 0 0 1
size-1024          12 16 1024 3 4 1
size-512(DMA)       0    0 512 0 0 1
size-512             9 16 512 2 2 1
size-256(DMA)       0    0 256 0 0 1
size-256             5 15 256 1 1 1
size-128(DMA)       0    0 128 0 0 1
size-128          847 870 128 29 29 1
size-64(DMA)       0    0 64 0 0 1
size-64          159 177 64 3 3 1
size-32(DMA)       0    0 32 0 0 1
size-32          2531 2599 32 23 23 1

大家注意看一下size-4096这一项，有2055个SLAB，每个SLAB占用4K的内存，那么2055*4=8M左右了，这个占用太大了，想请高手帮忙分析一下，为什么size-4096占用这么大的内存了？
能不能通过某种方法找出到底是哪些东西在占用size-4096？注明一下，系统此时没有跑任何的应用程序，系统初始化完毕就是这样的状态

iceyes342 发表于 2012-09-10 10:55

回复 1# chenrvmldd

我也碰到类似的问题了。你的问题解决了吗。请问，size-4096这些对象是做什么用的？kmalloc?

chenrvmldd 发表于 2012-09-20 19:46

回复 2# iceyes342

我找到了，是别人的代码导致的，呵呵

unbutun 发表于 2012-09-20 22:36

什么设备内存这么小

wy174828162 发表于 2013-01-18 11:28

请问一下是别人什么代码导致的。我也遇到类似的情况。遍历一个路径下的所有文件。如果路径下面有好多文件就导致freebuffer减少slab数据增加。不知道为什么？回复 3# chenrvmldd

action08 发表于 2014-12-04 17:49

回复 4# unbutun

智能小设备，不是纯计算机环境哦亲

7863612 发表于 2015-03-03 16:39

我最近也发现了这个问题，环境是嵌入式linux，64M内存，slab数据中SUnreclaim数据一上来就很高大概在30m左右，求解，楼主应用程序出现了什么问题？别的程序内存泄漏？回复 3# chenrvmldd

页: [1]

Chinaunix's Archiver

问一个关于slabinfo的问题