2015 年 8 月摘要

Question 1

我的结论是，这是 Linux 内核中某处发生的内核内存泄漏，这就是为什么没有一个用户空间工具能够显示内存泄漏的位置。也许这与这个问题有关：https://serverfault.com/questions/670423/linux-memory-usage-higher-than-sum-of-processes

我将内核版本从 3.13 升级到 3.19，似乎内存泄漏已经停止了！——如果我再次发现泄漏，我会报告。

有更简单的方法来查看 Linux 内核不同部分使用了多少内存仍然很有用。3.13 中导致泄漏的原因仍然是个谜。

Answer

我的结论是，这是 Linux 内核中某处发生的内核内存泄漏，这就是为什么没有一个用户空间工具能够显示内存泄漏的位置。也许这与这个问题有关：https://serverfault.com/questions/670423/linux-memory-usage-higher-than-sum-of-processes

我将内核版本从 3.13 升级到 3.19，似乎内存泄漏已经停止了！——如果我再次发现泄漏，我会报告。

有更简单的方法来查看 Linux 内核不同部分使用了多少内存仍然很有用。3.13 中导致泄漏的原因仍然是个谜。

Question 2

故事

我可以使用以下方法重现您的问题Linux 上的 ZFS。

node51这是一台具有RAM 的服务器20GB。我将16GiBRAM 标记为可分配给ZFS 自适应替换缓存 (ARC)：

root@node51 [~]# echo 17179869184 > /sys/module/zfs/parameters/zfs_arc_max
root@node51 [~]# grep c_max /proc/spl/kstat/zfs/arcstats
c_max                           4    17179869184

然后我45GiB使用以下方法读取文件管道查看器在我的 ZFS 池中zeltik填充 ARC：

root@node51 [~]# pv /zeltik/backup-backups/2014.04.11.squashfs > /dev/zero
  45GB 0:01:20 [ 575MB/s] [==================================>] 100%

现在看看可用内存：

root@node51 [~]# free -m
             total       used       free     shared    buffers     cached
Mem:         20013      19810        203          1         51         69
-/+ buffers/cache:      19688        324
Swap:         7557          0       7556

看！

51MiB缓冲区
69MiB中缓存
120MiB中
19688MiB正在使用的 RAM（包括缓冲区和缓存）
19568MiB正在使用的 RAM（不包括缓冲区和缓存）

您引用的 Python 脚本报告称应用程序仅使用了少量的 RAM：

root@node51 [~]# python ps_mem.py
 Private  +   Shared  =  RAM used       Program

148.0 KiB +  54.0 KiB = 202.0 KiB       acpid
176.0 KiB +  47.0 KiB = 223.0 KiB       swapspace
184.0 KiB +  51.0 KiB = 235.0 KiB       atd
220.0 KiB +  57.0 KiB = 277.0 KiB       rpc.idmapd
304.0 KiB +  62.0 KiB = 366.0 KiB       irqbalance
312.0 KiB +  64.0 KiB = 376.0 KiB       sftp-server
308.0 KiB +  89.0 KiB = 397.0 KiB       rpcbind
300.0 KiB + 104.5 KiB = 404.5 KiB       cron
368.0 KiB +  99.0 KiB = 467.0 KiB       upstart-socket-bridge
560.0 KiB + 180.0 KiB = 740.0 KiB       systemd-logind
724.0 KiB +  93.0 KiB = 817.0 KiB       dbus-daemon
720.0 KiB + 136.0 KiB = 856.0 KiB       systemd-udevd
912.0 KiB + 118.5 KiB =   1.0 MiB       upstart-udev-bridge
920.0 KiB + 180.0 KiB =   1.1 MiB       rpc.statd (2)
  1.0 MiB + 129.5 KiB =   1.1 MiB       screen
  1.1 MiB +  84.5 KiB =   1.2 MiB       upstart-file-bridge
960.0 KiB + 452.0 KiB =   1.4 MiB       getty (6)
  1.6 MiB + 143.0 KiB =   1.7 MiB       init
  5.1 MiB +   1.5 MiB =   6.5 MiB       bash (3)
  5.7 MiB +   5.2 MiB =  10.9 MiB       sshd (8)
 11.7 MiB + 322.0 KiB =  12.0 MiB       glusterd
 27.3 MiB +  99.0 KiB =  27.4 MiB       rsyslogd
 67.4 MiB + 453.0 KiB =  67.8 MiB       glusterfsd (2)
---------------------------------
                        137.4 MiB
=================================

19568MiB - 137.4MiB ≈ 19431MiB未记入 RAM 的

解释

您在上面的故事中看到的缓冲区120MiB和缓存的使用解释了内核缓存发送到外部设备或从外部设备接收的数据的有效行为。

第一行，标记为内存显示物理内存利用率，包括分配给缓冲区和缓存的内存量。缓冲区也称为缓冲存储器，通常被定义为内存的一部分，专门用于临时保存从外部设备（例如 HDD、键盘、打印机或网络）发送或接收的数据。

第二行数据以-/+ 缓冲区/缓存，显示当前用于系统的物理内存量缓冲区缓存这对于应用程序来说尤其有意义，因为通过使用读（）和写（） 系统调用通过此缓存。此缓存可以减少或消除对 HDD 或其他磁盘的读取或写入需求，从而大大加快数据访问速度。

^{_{来源：http://www.linfo.org/free.html}}

现在我们该如何解释失踪的情况19431MiB？

在free -m上面的输出中，19688MiB“用过的“ 在 ”-/+ 缓冲区/缓存“来自这个公式：

(kb_main_used) - (buffers_plus_cached) =
(kb_main_total - kb_main_free) - (kb_main_buffers + kb_main_cached)

kb_main_total:   MemTotal from /proc/meminfo
kb_main_free:    MemFree  from /proc/meminfo
kb_main_buffers: Buffers  from /proc/meminfo
kb_main_cached:  Cached   from /proc/meminfo

^{_{来源：procps/free.c和procps/proc/sysinfo.c}}

（如果您根据我的free -m输出计算数字，您会注意到2MiB没有考虑到这一点，但这是因为此代码引入了舍入误差#define S(X) ( ((unsigned long long)(X) << 10) >> shift)：）

这些数字也对不上号/proc/meminfo（我没有记录/proc/meminfo我运行的时间free -m，但是从您的问题中我们可以知道这/proc/meminfo并没有显示丢失的 RAM 在哪里），因此我们可以从上面得出结论，这/proc/meminfo并不能说明全部情况。

在我的测试条件下，我知道 Linux 上的 ZFS 是造成高 RAM 使用率的原因。我告诉它的 ARC，它最多可以使用16GiB服务器的 RAM。

Linux 上的 ZFS 不是一个进程。它是一个内核模块。

据我目前发现，内核模块的 RAM 使用情况不会使用进程信息工具显示出来，因为该模块不是一个进程。

故障排除

不幸的是，我对 Linux 了解不够，无法为您提供一种方法来列出非进程组件（如内核及其模块）正在使用的 RAM 数量。

此时，我们可以推测、猜测并检查。

您提供了dmesg输出。设计良好的内核模块会将其一些详细信息记录到dmesg。

看完之后dmesg，有一项内容引起了我的注意：FS-Cache

FS-Cache是内核模块的一部分，与Debian 和 Red Hat Enterprise Linux 上的cachefiles软件包相关。cachefilesd

也许不久前，您配置了FS-Cache一个 RAM 磁盘，以减少服务器分析视频数据时网络 I/O 的影响。

尝试禁用任何可能占用内存的可疑内核模块。它们可能被禁用blacklist在中/etc/modprobe.d/，后跟一个sudo update-initramfs -u（命令和位置可能因 Linux 发行版而异）。

结论

内存泄漏会消耗8MB/hr您的 RAM，并且似乎无论您做什么都不会释放 RAM。我无法根据您提供的信息确定内存泄漏的来源，也无法提供查找内存泄漏的方法。

需要有一位比我更有 Linux 经验的人提供意见，告诉我们如何确定“其他” RAM 的使用去向。

我已经开始对这个问题进行悬赏，看看我们是否可以得到比“推测、猜测和检查”更好的答案。

Answer

故事

我可以使用以下方法重现您的问题Linux 上的 ZFS。

node51这是一台具有RAM 的服务器20GB。我将16GiBRAM 标记为可分配给ZFS 自适应替换缓存 (ARC)：

root@node51 [~]# echo 17179869184 > /sys/module/zfs/parameters/zfs_arc_max
root@node51 [~]# grep c_max /proc/spl/kstat/zfs/arcstats
c_max                           4    17179869184

然后我45GiB使用以下方法读取文件管道查看器在我的 ZFS 池中zeltik填充 ARC：

root@node51 [~]# pv /zeltik/backup-backups/2014.04.11.squashfs > /dev/zero
  45GB 0:01:20 [ 575MB/s] [==================================>] 100%

现在看看可用内存：

root@node51 [~]# free -m
             total       used       free     shared    buffers     cached
Mem:         20013      19810        203          1         51         69
-/+ buffers/cache:      19688        324
Swap:         7557          0       7556

看！

51MiB缓冲区
69MiB中缓存
120MiB中
19688MiB正在使用的 RAM（包括缓冲区和缓存）
19568MiB正在使用的 RAM（不包括缓冲区和缓存）

您引用的 Python 脚本报告称应用程序仅使用了少量的 RAM：

root@node51 [~]# python ps_mem.py
 Private  +   Shared  =  RAM used       Program

148.0 KiB +  54.0 KiB = 202.0 KiB       acpid
176.0 KiB +  47.0 KiB = 223.0 KiB       swapspace
184.0 KiB +  51.0 KiB = 235.0 KiB       atd
220.0 KiB +  57.0 KiB = 277.0 KiB       rpc.idmapd
304.0 KiB +  62.0 KiB = 366.0 KiB       irqbalance
312.0 KiB +  64.0 KiB = 376.0 KiB       sftp-server
308.0 KiB +  89.0 KiB = 397.0 KiB       rpcbind
300.0 KiB + 104.5 KiB = 404.5 KiB       cron
368.0 KiB +  99.0 KiB = 467.0 KiB       upstart-socket-bridge
560.0 KiB + 180.0 KiB = 740.0 KiB       systemd-logind
724.0 KiB +  93.0 KiB = 817.0 KiB       dbus-daemon
720.0 KiB + 136.0 KiB = 856.0 KiB       systemd-udevd
912.0 KiB + 118.5 KiB =   1.0 MiB       upstart-udev-bridge
920.0 KiB + 180.0 KiB =   1.1 MiB       rpc.statd (2)
  1.0 MiB + 129.5 KiB =   1.1 MiB       screen
  1.1 MiB +  84.5 KiB =   1.2 MiB       upstart-file-bridge
960.0 KiB + 452.0 KiB =   1.4 MiB       getty (6)
  1.6 MiB + 143.0 KiB =   1.7 MiB       init
  5.1 MiB +   1.5 MiB =   6.5 MiB       bash (3)
  5.7 MiB +   5.2 MiB =  10.9 MiB       sshd (8)
 11.7 MiB + 322.0 KiB =  12.0 MiB       glusterd
 27.3 MiB +  99.0 KiB =  27.4 MiB       rsyslogd
 67.4 MiB + 453.0 KiB =  67.8 MiB       glusterfsd (2)
---------------------------------
                        137.4 MiB
=================================

19568MiB - 137.4MiB ≈ 19431MiB未记入 RAM 的

解释

您在上面的故事中看到的缓冲区120MiB和缓存的使用解释了内核缓存发送到外部设备或从外部设备接收的数据的有效行为。

第一行，标记为内存显示物理内存利用率，包括分配给缓冲区和缓存的内存量。缓冲区也称为缓冲存储器，通常被定义为内存的一部分，专门用于临时保存从外部设备（例如 HDD、键盘、打印机或网络）发送或接收的数据。

第二行数据以-/+ 缓冲区/缓存，显示当前用于系统的物理内存量缓冲区缓存这对于应用程序来说尤其有意义，因为通过使用读（）和写（） 系统调用通过此缓存。此缓存可以减少或消除对 HDD 或其他磁盘的读取或写入需求，从而大大加快数据访问速度。

^{_{来源：http://www.linfo.org/free.html}}

现在我们该如何解释失踪的情况19431MiB？

在free -m上面的输出中，19688MiB“用过的“ 在 ”-/+ 缓冲区/缓存“来自这个公式：

(kb_main_used) - (buffers_plus_cached) =
(kb_main_total - kb_main_free) - (kb_main_buffers + kb_main_cached)

kb_main_total:   MemTotal from /proc/meminfo
kb_main_free:    MemFree  from /proc/meminfo
kb_main_buffers: Buffers  from /proc/meminfo
kb_main_cached:  Cached   from /proc/meminfo

^{_{来源：procps/free.c和procps/proc/sysinfo.c}}

（如果您根据我的free -m输出计算数字，您会注意到2MiB没有考虑到这一点，但这是因为此代码引入了舍入误差#define S(X) ( ((unsigned long long)(X) << 10) >> shift)：）

这些数字也对不上号/proc/meminfo（我没有记录/proc/meminfo我运行的时间free -m，但是从您的问题中我们可以知道这/proc/meminfo并没有显示丢失的 RAM 在哪里），因此我们可以从上面得出结论，这/proc/meminfo并不能说明全部情况。

在我的测试条件下，我知道 Linux 上的 ZFS 是造成高 RAM 使用率的原因。我告诉它的 ARC，它最多可以使用16GiB服务器的 RAM。

Linux 上的 ZFS 不是一个进程。它是一个内核模块。

据我目前发现，内核模块的 RAM 使用情况不会使用进程信息工具显示出来，因为该模块不是一个进程。

故障排除

不幸的是，我对 Linux 了解不够，无法为您提供一种方法来列出非进程组件（如内核及其模块）正在使用的 RAM 数量。

此时，我们可以推测、猜测并检查。

您提供了dmesg输出。设计良好的内核模块会将其一些详细信息记录到dmesg。

看完之后dmesg，有一项内容引起了我的注意：FS-Cache

FS-Cache是内核模块的一部分，与Debian 和 Red Hat Enterprise Linux 上的cachefiles软件包相关。cachefilesd

也许不久前，您配置了FS-Cache一个 RAM 磁盘，以减少服务器分析视频数据时网络 I/O 的影响。

尝试禁用任何可能占用内存的可疑内核模块。它们可能被禁用blacklist在中/etc/modprobe.d/，后跟一个sudo update-initramfs -u（命令和位置可能因 Linux 发行版而异）。

结论

内存泄漏会消耗8MB/hr您的 RAM，并且似乎无论您做什么都不会释放 RAM。我无法根据您提供的信息确定内存泄漏的来源，也无法提供查找内存泄漏的方法。

需要有一位比我更有 Linux 经验的人提供意见，告诉我们如何确定“其他” RAM 的使用去向。

我已经开始对这个问题进行悬赏，看看我们是否可以得到比“推测、猜测和检查”更好的答案。

Question 3

你改变了Swapiness手动关闭内核或者禁用它？

您可以使用

cat /proc/sys/vm/swappiness

你可以尝试强制你的内核进行积极交换

sudo sysctl -w vm.swappiness=100

如果这会减少您的问题，请在 1 到 100 之间找到一个适合您要求的好值。

Answer

你改变了Swapiness手动关闭内核或者禁用它？

您可以使用

cat /proc/sys/vm/swappiness

你可以尝试强制你的内核进行积极交换

sudo sysctl -w vm.swappiness=100

如果这会减少您的问题，请在 1 到 100 之间找到一个适合您要求的好值。

Question 4

您说得不完全正确 – 是的，您的 free –m 命令显示可用 220MB，但它还显示 1771MB 用作缓冲区。缓冲区和缓存是内核用来优化对慢速访问数据（通常是磁盘）的访问的内存。因此，您应该将所有标记为缓冲区的内存视为可用内存，因为内核可以在需要时将其取回。

看：https://serverfault.com/questions/23433/in-linux-what-is-the-difference-between-buffers-and-cache-reported-by-the-f

Answer

您说得不完全正确 – 是的，您的 free –m 命令显示可用 220MB，但它还显示 1771MB 用作缓冲区。缓冲区和缓存是内核用来优化对慢速访问数据（通常是磁盘）的访问的内存。因此，您应该将所有标记为缓冲区的内存视为可用内存，因为内核可以在需要时将其取回。

看：https://serverfault.com/questions/23433/in-linux-what-is-the-difference-between-buffers-and-cache-reported-by-the-f

2015 年 8 月摘要

2015 年 8 月摘要

顶部

硬件

应用

万明信息

自由输出

PS 输出

PS 内存输出

板顶输出

其他

结论

答案1

答案2

故事

解释

故障排除

结论

答案3

答案4

相关内容