查找消耗内存的进程

查找消耗内存的进程

盒子有 96GB 内存,无交换。

# free -m
             total       used       free     shared    buffers     cached
Mem:         96714      85762      10952          0         94       2185
-/+ buffers/cache:      83482      13232
Swap:            0          0          0

看起来正在使用 85GB 内存,但是从 top 命令中,排序依据%MEM

只使用了32GB内存,剩下的都去哪了?

在此输入图像描述

有任何想法吗?

编辑

# cat /proc/meminfo
MemTotal:         99036140     kB
MemFree:          10901516     kB
Buffers:          126816       kB
Cached:           2355968      kB
SwapCached:       0            kB
Active:           35103352     kB
Inactive:         2973732      kB
Active(anon):     34352040     kB
Inactive(anon):   1793248      kB
Active(file):     751312       kB
Inactive(file):   1180484      kB
Unevictable:      1892         kB
Mlocked:          0            kB
SwapTotal:        0            kB
SwapFree:         0            kB
Dirty:            8864         kB
Readahead:        0            kB
Writeback:        0            kB
AnonPages:        35596308     kB
Mapped:           693268       kB
Shmem:            549000       kB
Slab:             48846688     kB
SReclaimable:     48771520     kB
SUnreclaim:       75168        kB
KernelStack:      9864         kB
PageTables:       108668       kB
NFS_Unstable:     0            kB
Bounce:           0            kB
WritebackTmp:     0            kB
CommitLimit:      49518068     kB
Committed_AS:     41937368     kB
VmallocTotal:     34359738367  kB
VmallocUsed:      500436       kB
VmallocChunk:     34290219936  kB
HugePages_Total:  0
HugePages_Free:   0
HugePages_Rsvd:   0
HugePages_Surp:   0
Hugepagesize:     2048         kB
DirectMap4k:      7252         kB
DirectMap2M:      100620288    kB

答案1

总内存 = 可用内存 + 缓存/缓冲区 + 活动 + 不活动

         = 10901516 + 126816 + 2355968 + 35103352 + 2973732
         = 51461384 KB
         = 49 GB 

缺少内存 = 96 GB - 49 GB = 47 GB 缺少的内存几乎等于平板内存(48846688 kB),我猜测某些内核模块正在泄漏内存。

请打印 /proc/slabinfo 和labtop 命令输出以进行更多调查,如果您在 vmware 上运行,还可以打印 vmware-toolbox-cmd stat bubble 和 vmware-toolbox-cmd stat memlimit 的输出。

编辑

看起来有 dentry 内核模块消耗了 48646536kB ,在互联网上搜索我发现https://serverfault.com/questions/561350/unusually-high-dentry-cache-usage,这表明问题来自罪魁祸首是与 Libcurl 捆绑在一起的 NSS(网络安全服务)库

您至少只需升级 nss-softokn(它对 nss-utils 具有必需的依赖性)。为了获得好处,您需要为使用 libcurl 的进程设置环境变量 NSS_SDB_USE_CACHE。该环境变量的存在使得可以跳过代价高昂的不存在文件检查。”

尝试一下并告诉我们。

相关内容