Ubuntu 16.04 从未交换

Ubuntu 16.04 从未交换

我在笔记本电脑上使用 Xubuntu 16.04,它是从 Xubuntu 14 的 dist-upgrade 安装的。

该笔记本电脑有 10 GB RAM 和 4 GB 交换空间。

最近我将内核升级到版本:4.15.0-51。

问题在于,在正常运行期间,系统会随着时间的推移而进行换出,但从不会换回。因此,经过数小时/数天的正常运行后,交换空间就会变满。

即使关闭所有主进程,RAM 使用量仍会达到几百 MB,但交换空间仍保持满负荷。此外,循环遍历所有进程/proc/*/statsgrep VmSwap返回 0 kB。

我该如何调试内核未交换的原因?

这就像内核失去了对交换页面所属进程的追踪一样。

我已经投入了大量时间来尝试修复此问题,但没有成功。目前我唯一的办法是使用一个脚本来创建和回收(swapoff ; swapon)一些交换文件。

感谢您的任何帮助。

答案1

今天我又试了一下,发现了问题。

首先再次检查 meminfo 信息。以下是输出cat /proc/meminfo

MemTotal:       10133276 kB
MemFree:         2617372 kB
MemAvailable:    4660420 kB
Buffers:          503472 kB
Cached:          3825884 kB
SwapCached:        59448 kB
Active:          3852624 kB
Inactive:        3112996 kB
Active(anon):    2688920 kB
Inactive(anon):  2245220 kB
Active(file):    1163704 kB
Inactive(file):   867776 kB
Unevictable:          32 kB
Mlocked:              32 kB
SwapTotal:       6096888 kB
SwapFree:        2644324 kB
Dirty:                52 kB
Writeback:             0 kB
AnonPages:       2576972 kB
Mapped:           770460 kB
Shmem:           2297836 kB
Slab:             391072 kB
SReclaimable:     325960 kB
SUnreclaim:        65112 kB
KernelStack:       15824 kB
PageTables:        53492 kB
NFS_Unstable:          0 kB
Bounce:                0 kB
WritebackTmp:          0 kB
CommitLimit:    11163524 kB
Committed_AS:   12259512 kB
VmallocTotal:   34359738367 kB
VmallocUsed:           0 kB
VmallocChunk:          0 kB
HardwareCorrupted:     0 kB
AnonHugePages:      2048 kB
ShmemHugePages:        0 kB
ShmemPmdMapped:        0 kB
CmaTotal:              0 kB
CmaFree:               0 kB
HugePages_Total:       0
HugePages_Free:        0
HugePages_Rsvd:        0
HugePages_Surp:        0
Hugepagesize:       2048 kB
DirectMap4k:      349640 kB
DirectMap2M:    10039296 kB

尽管存在 4 GB 交换空间未被占用的问题,但这次 2GB 共享内存的使用引起了我的注意。

搜索时,我找到了这个问题及其答案: SHMem 内存使用率过高!

因此,简而言之,shmem 使用率高可能与 tmpfs 目录有关。在我的例子中,/dev使用了近 4.8 GB

以下是输出df -h

Filesystem      Size  Used Avail Use% Mounted on
udev            4,8G  4,8G     0 100% /dev
tmpfs           990M   34M  956M   4% /run
/dev/sda2       255G  232G   11G  96% /
tmpfs           4,9G  220M  4,7G   5% /dev/shm
tmpfs           5,0M  4,0K  5,0M   1% /run/lock
tmpfs           4,9G     0  4,9G   0% /sys/fs/cgroup
/dev/sda5       333G  208G  126G  63% /media/dados
cgmfs           100K     0  100K   0% /run/cgmanager/fs
tmpfs           990M   88K  990M   1% /run/user/1000

之后,我/dev使用该命令搜索罪魁祸首du。正如我在上面链接的帖子中提到的,正是该bootchart命令在目录中存储了大量日志文件/dev

谢谢您的帮助。

答案2

你不必担心。例如这里。内核正在跟踪它并且可以重新使用交换中的空间。

相关内容