【问题标题】:linux high slab cache usagelinux高slab缓存使用情况
【发布时间】:2013-04-11 02:54:50
【问题描述】:

在我的一台服务器上,我有一些内存/磁盘 KV 服务, 内存 KV 的行为类似于 memcached,在初始化时要求大量内存(10GB), Disk Kv 的行为类似于 leveldbd,它的随机读取和顺序写入,并且它经常读取大量文件。 内存全部使用 libc malloc 分配。

我的KV服务器进程没有消耗大量内存如下(由于内存不足,我已经杀死了内存KV,只留下磁盘KV,但可用内存仍然下降):

:~$top
PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
20 0 5030m 3.9g 2772 S 8 6.1 10430:52 tair_server
20 0 4833m 3.9g 4560 S 8 6.1 10171:07 tair_server
20 0 4844m 3.9g 3844 S 38 6.1 10073:32 tair_server
20 0 4765m 3.8g 4144 S 8 6.0 10552:39 tair_server
20 0 2941m 2.4g 9.8m S 0 3.8 256:45.70 tair_server
20 0 2953m 2.4g 12m S 1 3.7 276:54.64 tair_server

但是,我的记忆消失了。

$free -m

             total       used       free     shared    buffers     cached
Mem:         64552      57778       6774          0         16        326
-/+ buffers/cache:      57435       7117
Swap:            0          0          0

我可以看到slab消耗了我的大量内存,而且它是不可回收的。

$cat /proc/meminfo
MemTotal:       66101892 kB
MemFree:         6816228 kB
Buffers:           17024 kB
Cached:           456640 kB
SwapCached:            0 kB
Active:         19697712 kB
Inactive:        3197312 kB
Active(anon):   19546504 kB
Inactive(anon):  2875632 kB
Active(file):     151208 kB
Inactive(file):   321680 kB
Unevictable:          48 kB
Mlocked:               0 kB
SwapTotal:             0 kB
SwapFree:              0 kB
Dirty:              6612 kB
Writeback:            72 kB
AnonPages:      22421152 kB
Mapped:            54408 kB
Shmem:               332 kB
Slab:           28870400 kB
SReclaimable:     213344 kB
SUnreclaim:     28657056 kB
KernelStack:       30000 kB
PageTables:        62776 kB
NFS_Unstable:          0 kB
Bounce:                0 kB
WritebackTmp:          0 kB
CommitLimit:    33050944 kB
Committed_AS:   37517224 kB
VmallocTotal:   34359738367 kB
VmallocUsed:      388624 kB
VmallocChunk:   34324313700 kB
HardwareCorrupted:     0 kB
HugePages_Total:       0
HugePages_Free:        0
HugePages_Rsvd:        0
HugePages_Surp:        0
Hugepagesize:       2048 kB
DirectMap4k:        5696 kB
DirectMap2M:     2082816 kB
DirectMap1G:    65011712 kB

这是平板信息。

$slabtop -s c

OBJS ACTIVE  USE OBJ SIZE  SLABS OBJ/SLAB CACHE SIZE NAME  
69842766 69838389  38%    0.19K 1663025       42  13304200K kmalloc-192
69314912 69314796  38%    0.12K 2166091       32   8664364K kmalloc-128
70866624 70866323  39%    0.06K 1107291       64   4429164K kmalloc-64
69299968 69299592  38%    0.03K 541406      128   2165624K kmalloc-32
128388  72434  56%    0.99K   4230       32    135360K ext4_inode_cache
208782  94112  45%    0.19K   4971       42     39768K dentry

我不明白什么会消耗大量内存,为什么会这样,以及如何解决这个问题。

这可能是间隔内核错误吗?

或者是glibc的问题,由于频繁的磁盘读取,它没有将内存返回给系统?

【问题讨论】:

  • 通常当有人问“我所有的 Linux 内存都去哪儿了”时,答案是“磁盘缓存,这不是问题”,但我不知道这里是不是这样。服务器故障可能是一个更好的地方。或许看看这个问题:serverfault.com/questions/240277/…
  • 引用的服务器故障问题涉及高 SReclaimable,这是与 SUnreclaimable 完全不同的野兽 - 这似乎是这里的问题。我现在正在研究一个类似的问题,其中 64、128 和 192 字节的 SOA 分配似乎正在“泄漏”。这是一个老问题,但如果我发现任何问题,我会回来报告。同时,如果有人知道 SOA 分配如何在 Linux 中泄露,我会喜欢你的想法。
  • @J.Paulding 我也在调查类似的问题。你找到的任何东西。
  • 到目前为止,只有死胡同。我认为最好的温暖线索似乎将增长与一个名为 S3Cmd 的 python 工具联系起来,该工具在 cron 作业上运行。由于其他原因,我们已经更改了服务器上的技术堆栈 - 目前没有问题。但我从来没有找到确凿的证据。对不起。我很想听听你是否有任何进展!

标签: linux memory


【解决方案1】:

看起来您的发行版有点旧,但没关系。不要听那些告诉你必须先升级才能查看unmae -a 输出的人。但是,如果您提供它会很好......

在较新版本的服务器和桌面发行版中,免费命令输出和/proc/meminfo 包含多行,目的是消除您遇到的那种混淆。行名称在/proc/meminfo 中为“MemAvailable”,在free 输出中为“available”。

free -m 中的“free”列并未以人类理解的方式显示可用内存(/proc/meminfo 中的“MemFree”行也是如此)。它不排除内核的页面缓存和其他没有以人类理解的方式“使用”的缓存。

这是第一件事。如果您认为我错了并且您正确理解了free 输出,请尝试:echo 3 > /proc/sys/vm/drop_caches,然后看看内存使用情况会发生什么。请在以 root 身份执行该命令后提供free 的输出。

如果还是那么糟糕,请阅读:https://www.linuxquestions.org/questions/linux-server-73/very-high-slab-usage-hard-to-understand-901323/。它说您的内核可能需要升级。

【讨论】:

    【解决方案2】:

    随top , free ,slabtop 的摘录提供

    看起来你的内核正在消耗内存 平板:28870400 kB

    找到这个的一个非常简单的方法是 .

    1. 做一个 Top ,并做一个 RES 内存的总和(RAM 上的常驻内存), top 只给出内存的用户视图。

    2. 做一个 free -m 看看有多少内存是空闲和使用的(free given kernel + user)。总内存 - top RES 与 FREE 命令中被称为 free 的内存之间的差异不应太大 ~1 GB

    “是时候提升你的操作系统版本了”

    【讨论】:

      猜你喜欢
      • 2013-02-07
      • 1970-01-01
      • 1970-01-01
      • 2012-01-12
      • 2012-05-07
      • 1970-01-01
      • 1970-01-01
      • 2011-04-08
      • 1970-01-01
      相关资源
      最近更新 更多