我正在运行一个经常出现内存不足的桌面系统，这促使我进行调查什么首先导致这个问题。
问题是，没有一个进程会消耗内存，但系统不会将其显示为可用。更重要的是，系统确实进行了交换，因此看起来内存压力是真实存在的。令人费解的是，在我注销并再次返回后，使用情况恢复正常（使用了约 1GB），因此看起来像是用户空间和内核之间的一些奇怪的交互，而不是内存泄漏。
简而言之：
- 报告使用的内存
free，不包括缓存/缓冲区：3173960 kB - 所有应用程序的 USS 总和：2413952 kB
- SLAB 大小：158968 kB
- zram（压缩后）：75992 kB
这给出了3173960-2413952-158968-75992 = 525048 kB未计算的内存使用情况。
我错过了什么或没有计算什么？
应用程序内存使用总和：
# smem -t | sed -n '1p;$p'
PID User Command Swap USS PSS RSS
108 6 244524 2413952 2461340 2648488
报告的内存使用情况free：
# free -k
total used free shared buffers cached
Mem: 4051956 3449748 602208 0 26548 249240
-/+ buffers/cache: 3173960 877996
Swap: 4051952 242592 3809360
一般内存统计：
# cat /proc/meminfo
MemTotal: 4051956 kB
MemFree: 612260 kB
Buffers: 26636 kB
Cached: 249304 kB
SwapCached: 107892 kB
Active: 1774004 kB
Inactive: 885268 kB
Active(anon): 1712484 kB
Inactive(anon): 710788 kB
Active(file): 61520 kB
Inactive(file): 174480 kB
Unevictable: 9332 kB
Mlocked: 9332 kB
SwapTotal: 4051952 kB
SwapFree: 3809368 kB
Dirty: 40 kB
Writeback: 0 kB
AnonPages: 2343292 kB
Mapped: 95288 kB
Shmem: 36396 kB
Slab: 158968 kB
SReclaimable: 53900 kB
SUnreclaim: 105068 kB
KernelStack: 3528 kB
PageTables: 43600 kB
NFS_Unstable: 0 kB
Bounce: 0 kB
WritebackTmp: 0 kB
CommitLimit: 6077928 kB
Committed_AS: 4013288 kB
VmallocTotal: 34359738367 kB
VmallocUsed: 139852 kB
VmallocChunk: 34359570976 kB
HardwareCorrupted: 0 kB
AnonHugePages: 641024 kB
HugePages_Total: 0
HugePages_Free: 0
HugePages_Rsvd: 0
HugePages_Surp: 0
Hugepagesize: 2048 kB
DirectMap4k: 2310848 kB
DirectMap2M: 1882112 kB
掉期已开启zram：
# cat /proc/swaps
Filename Type Size Used Priority
/dev/zram0 partition 2025976 121252 100
/dev/zram1 partition 2025976 121324 100
# awk ' { print $0 / 1024; sum+=$0 } END { print "sum:" sum/1024 } ' /sys/block/zram*/compr_data_size
37962.4
38030.1
sum:75992.5
答案1
问题
4 GB RAM（物理内存），并且您有 2 个最大 2,025,976 kB 的 zram 设备（每个大约 2 GB）。 zram 正在使用可用内存，我不确切地知道内部，但无论机制如何，我可以清楚地想象一个场景：Linux 页面调出（= 将一些内存从 RAM 放入 zram）以获得更多可用空间，然后 zram 使用情况内存中的内存不断增长，因此它将进一步分页，这将导致 zram 使用量进一步增加，依此类推，直到 zram 耗尽所有物理内存。
我猜想任何系统上都有一个阈值，在这个阈值下，分页不会对内核产生如上所述的压力，因此 zram 可以提高性能。
见解
当您的系统想要交换 100 MB 时，会发生的情况是将这 100 MB 放入 zram 中。假设它被压缩到 50%，即 50 MB。这意味着您的系统想要释放 100 MB，但只释放了 50 MB。现在Linux很聪明，因为当它调出一块内存（因此将它们放入交换区）但再次需要它们时，它可以做一些“优化”，它可以再次调入该内存但也将其保留在交换区中，因此如果很快需要调出内存的这些部分，则可以避免对交换文件进行昂贵的写入。因此，在您的情况下，Linux 可能会将 100 MB 保留在 zram 中，并将它们放回普通 RAM 中，因此系统会暂时消耗 150 MB。如果对可压缩数据较少的较大程序重复此操作，这可能很快就会成为一场噩梦，想象一下将被调出的 300 MB RAM 块，并在每个 zram 交换中使用 120 MB。这意味着 Linux 想要释放 300 MB 的 RAM 用于其他目的，但只释放了 (300-120-120=60) 60 MB，然后它可能会尝试调出更多页面，依此类推，问题是您有 2 个 zram，每个 zram 最多可使用 2 GB RAM，从而耗尽您的所有内存。
结论及解决方案
那么zram是垃圾吗？不，一点也不，问题在于您将 zram 配置为具有与物理 RAM 完全相同的总大小，这就是问题所在。恕我直言，您不应将 zram 配置为使用超过 25% 的物理 RAM，这意味着一旦 zram 交换已填满，您将不得不仍然依赖硬盘交换解决方案。
一个简单的解决方案是减少 zram 以处理每个 500 MB 的最大值，并添加大约 2-3 GB 的交换文件，以允许内核将真正未使用的页面从 zram 释放到此交换文件。交换文件不会使用 RAM，从而减轻 RAM 的压力。
一些信息如何设置 zram 磁盘大小。
答案2
我发现确实smem可以看到已使用的内存，但只能在“系统”模式下：
# smem -tw
Area Used Cache Noncache
firmware/hardware 0 0 0
kernel image 0 0 0
kernel dynamic memory 1200240 379444 820796
userspace memory 2101184 136800 1964384
free memory 750532 750532 0
----------------------------------------------------------
4051956 1266776 2785180
# free -k
total used free shared buffers cached
Mem: 4051956 3298200 753756 0 31664 425552
-/+ buffers/cache: 2840984 1210972
Swap: 4051952 237368 3814584
free这使得和之间的非缓存使用内存之间（几乎没有）大约 55MiB 的差异smem。
答案3
该free -tm命令还显示通过 tmpfs 支持的文件的交换使用情况。如果您可以清空/tmp文件夹，则 的内存使用量smem -t -k应该与 类似free -tm。