linux各发行版大量磁盘操作后cache缓存太高，桌面卡死的分析- Community

linux各发行版大量磁盘操作后cache缓存太高，桌面卡死的分析

Experiences and Insight 1.1w views · 82 replies ·

peacekeep

deepin

2020-07-18 03:01

Author

本帖最后由 peacekeep 于 2020-8-2 09:06 编辑

      刚刚看到有人说深度文件管理器在ntfs拷贝大文件会出现速度慢、系统卡死的情况。正好，我这两天刚刚测试了类似的问题：在linux各发行版下，大量磁盘操作后buffer/cache缓存过高，桌面卡死的情况。
      首次发现这个问题是前两年编译aosp时，使用的系统时Ubuntu16.04。编译结束后，桌面直接卡死，无法操作。当时以为是系统过热的问题，毕竟是用的笔记本，直接强制关机了。后来多次出现同样的问题，感觉很奇怪，就用free -h查看了一下内存使用情况。结果显示内存 used 很正常1-2G左右吧，而free仅省了几百M，大量内存被buff/cache占用。
      这个buff/cache是干什么的呢？详细的可以看一下下面这个博客。

https://blog.csdn.net/u013427969/article/details/83315104

简单说，就是读写磁盘的时候，内核会在内存中缓存磁盘的内容，便于以后读取方便，提高磁盘的I/O性能。内存将要耗尽的时候，内核又会回收这部分内存给其他进程使用。这样buff/cache缓存所占据的内存其实是可用内存。理论上，即使buff/cache占据了大部分的内存，也不会影响系统的稳定性。
不过，在linux桌面系统中，进行大量磁盘读写操作后，常见的就是拷贝大文件或者大量小文件，桌面就会卡死。使用下面3条任意一个释放buff/cache缓存后，均能改善。

echo 1 > /proc/sys/vm/drop_caches
echo 2 > /proc/sys/vm/drop_caches
echo 3 > /proc/sys/vm/drop_caches

Copy the Code

因此当时一直认为是内存不足导致的卡顿，也没多想。这几天拷贝文件时又遇见了这个问题，就想着如何调整内核参数限制buffer/cache。

## 调整内核参数，控制内存
vm.dirty_ratio = 1
vm.dirty_background_ratio=1
vm.dirty_writeback_centisecs=2
vm.dirty_expire_centisecs=1500
vm.drop_caches=3
vm.swappiness =100
vm.min_free_kbytes=409600
vm.vfs_cache_pressure=200
vm.overcommit_ratio = 10
vm.overcommit_memory=2
vm.lowmem_reserve_ratio=32 32 8
kern.maxvnodes=3

Copy the Code

实际上，多次调整并没有改善大量文件拷贝过程中出现的卡顿问题。但在调整过程发现，卡顿出现的时间点跟缓存释放，buff/cache降低，free增加的时间点基本吻合。导致卡顿的问题可能不是内存太小，而是buff/cache释放的过程。为此，使用如下脚本（drop_caches.sh）进行了测试：

while true
do
echo 2 > /proc/sys/vm/drop_caches
done

Copy the Code

      用root用户运行该脚本，观察桌面，卡的很，比之前拷贝文件都卡，鼠标键盘延迟非常大。不仅是鼠标键盘，播放视频时，画面也是卡成狗，但声音完全正常。
      测试echo 3 > /proc/sys/vm/drop_caches有同样的效果，但是echo 1 > /proc/sys/vm/drop_caches没有影响。按照内核文档的说法，echo 2 > /proc/sys/vm/drop_caches 是 to free dentries and inodes 的，也就这个过程导致了桌面卡顿。（echo 3 > /proc/sys/vm/drop_caches 包括可1和2的作用，所以也卡）。
      linux系统那么多年了，作为非常常用的服务器操作系统，大量的I/O操作在所难免，不至于连这点内存管理的能力都没有。感觉问题肯定在内核之外。那么服务器上没事，桌面系统有事，那基本就是桌面的事了。那么会不会是某个desktop environment（桌面环境）的问题？并不。在Gnome、KDE、DDE等多个桌面环境里都是一样的。那最有可能的就是Xorg了。
      对此，又在终端环境和安卓X86环境下运行了同样的脚本以及大量文件拷贝工作，系统运行都很正常，无论是视频播放还是其他操作，都没有输入和画面输出的卡顿问题。可以基本确认是Xorg或与其相关组件的导致的系统卡顿了。不过还有几个疑点，一是安卓x86内核跟桌面linux内核的配置略有不同，二是没有针对wayland测试。后面统一一下内核对安卓x86再测试一下，还有就是用weston环境测试一下。

2020.7.19
1、在weston环境下测试，关闭Xorg，依然卡顿，不过整体流畅度比Xorg要高。在wayland的KDE环境下效果跟Xorg下相当。
2、根据rekees2020 的反馈关闭swap之后，就不存在卡顿的问题了。实际测试，swapoff -a以后确实就不卡了！运行drop_caches.sh脚本也不卡。可见问题同swap有关。

2020.7.20
1、Android X86环境（openthos live）测试：默认swap是关闭的，运行drop_caches.sh脚本以及大量文件拷贝都不卡顿。手动swapon以后运行drop_caches.sh脚本不卡，swap并没有占用；大量文件拷贝以后卡顿，swap仅占用40-50M。
2、Ubuntukylin 20.04（livecd）测试：swapon的情况下，运行drop_caches.sh脚本以及大量文件拷贝都不卡顿。运行drop_caches.sh，swap并没有占用；大量文件拷贝swap仅占用10-60M。（内核版本号5.4.0-40）

2020.7.21
1、根据rekees2020 的反馈，开启zswap后可以在保持swap分区的情况下，不卡顿。
测试：root用户下，echo 1 > /sys/module/zswap/parameters/enabled，运行drop_caches.sh脚本以及大量文件拷贝都不卡顿。
zswap的开启方式可以参考内核文档：https://www.kernel.org/doc/Documentation/vm/zswap.txt及https://ywnz.com/linuxjc/5492.html
简单说有三种方式：一是在启动内核时CMDLINE里添加，比如修改grub.cfg，增加zswap.enabled=1；二是系统启动完成后在root用户下echo 1 > /sys/module/zswap/parameters/enabled，三是通过第三方管理软件开启，例如systemd-swap。
2、KDE NEON更新内核至5.4.0-40之后，发现问题竟然解决了，哈哈哈。运行drop_caches.sh脚本以及大量文件拷贝都不卡，swap占用始终为0。这么说，这个问题应该算是历史问题了。linux kernel开发组也许是发现了问题根源并解决了。回头看看commithistory是哪里的问题。
2020.7.22
1、在UOS 个人体验版（内核版本：5.3.0-3-amd64）中，echo 1 > /sys/module/zswap/parameters/enabled开启zswap后，运行drop_caches.sh脚本测试，系统卡顿减轻，但是依然是有明显的卡顿。swapoff -a 彻底关闭swap，运行drop_caches.sh脚本完全不卡。UOS官方源没有5.4及以后的内核，故没有测试。

2020.7.25
1、UOS中使用自己编译的5.4.0和5.4.44内核(kernel.org官方源码)，swapon&zswapoff的情况下卡顿依然。config文件：config.5.4.zip

2、UOS中使用自己编译的5.7.7内核(kernel.org官方源码)，swapon&zswapoff的情况下完全无卡顿。config文件：config-5.7.zip

2020.7.26

1、UOS中使用自己编译的5.4.0、5.4.44、5.4.45、5.4.53内核(kernel.org官方源码)，swapon&zswapoff的情况下卡顿依然。config文件与：5.7的接近
2、UOS中使用自己编译的5.5.0、5.5.0-rc1内核(kernel.org官方源码)，swapon&zswapoff的情况下完全无卡顿。config文件与：5.7的接近
3、以上所有不卡顿的内核，在执行drop_caches.sh脚本测试及大量文件拷贝时，虽然开启了swap，但是系统很少会去使用swap，基本上就是不去用。所有卡顿的内核都会去用swap，比较频繁的使用，但使用的空间量不大。

8.2
卡顿的直接原因极有可能是系统回收内存的过程中把桌面要用的一部分内存页回收到swap里了。所以关闭swap就不卡了，而使用zswap可以缓解卡顿。

Reply Like 0 Favorite View the author

All Replies

2 / 5

rekees2020

deepin

2020-07-18 21:07

#21

https://bbs.deepin.org/post/197314
我觉得还是内核配置的问题，因为linux在服务器上是没有硬件瓶颈的，而桌面硬件都有普遍的瓶颈，在设计的时 ...

ubuntu论坛上有人也说与内核有关，还说新版内核会解决，不知道发那帖子时是哪个版本内核
我也不敢贸然升级内核

Reply Like 0 View the author

rekees2020

deepin

2020-07-18 21:14

#22

https://bbs.deepin.org/post/197314
提供一下经历，上次复制备份文件，大约600G，包含大量小文件，使用rsync命令备份复制的，全程无卡顿... ...

值得一试
能完全无视复制过程去操作其他程序？
我遇到卡顿的情况都是拷单个巨大的文件，没留意小文件

Reply Like 0 View the author

ylxdxx

deepin

2020-07-18 21:21

#23

https://bbs.deepin.org/post/197314
值得一试
能完全无视复制过程去操作其他程序？
我遇到卡顿的情况都是拷单个巨大的文件，没留意小文件 ...

里面也有一些大文件，像一些镜像的备份，当时除了感觉硬盘所在区域发热量巨大外，跟平常无异

Reply Like 0 View the author

rekees2020

deepin

2020-07-18 21:49

#24

https://bbs.deepin.org/post/197314
里面也有一些大文件，像一些镜像的备份，当时除了感觉硬盘所在区域发热量巨大外，跟平常无异 ...

测试过了，用rsync在局域网上复制确实是已知方式中最顺畅的，复制进程放着不管，同时操作其他程序，只在最开始有非常轻微的、可忽略的一点点卡顿
用rsync本地复制卡顿依然严重，不过比直接用文件浏览器复制好很多

Reply Like 0 View the author

rekees2020

deepin

2020-07-18 21:57

#25

rsync从本地拷到局域网内的服务器比较顺畅，但是反过来拷到本地就又有明显卡顿
看来还是绕不过缓存的问题

Reply Like 0 View the author

说书人

deepin

2020-07-18 22:23

#26

是不是swap的锅

Reply Like 0 View the author

rekees2020

deepin

2020-07-18 22:26

#27

https://bbs.deepin.org/post/197314
是不是swap的锅

怀疑过
8200M的swap分区，拷完文件时查看占用900多M
只知道怎么完全不用swap，但是不知道怎么部分停用，不想禁用休眠

Reply Like 0 View the author

wc******20@gmail.com

deepin

2020-07-18 22:49

#28

不错，有想法，哈哈

Reply Like 0 View the author

ltree

deepin

2020-07-18 23:04

#29

https://bbs.deepin.org/post/197314
ubuntu论坛上有人也说与内核有关，还说新版内核会解决，不知道发那帖子时是哪个版本内核
我也不敢贸然升 ...

如果系统拿来只是玩玩的话可以升一下，做好重装的准备就行233,重装只有零次和无数次

Reply Like 0 View the author

Comments

wnmer

2020-07-21 23:53

这是正解，我学linux的过程就是一个不断重装linux的过程。

random0901

deepin

2020-07-18 23:05

#30

https://bbs.deepin.org/post/197314
是KDE吗？如果是的话，禁用baloo试试。我以前用KDE的时候有时也会莫名其妙变卡，CPU和内存占用都不高，就 ...

deepin应该没有使用baloo

Reply Like 0 View the author

SamLukeYes

deepin

2020-07-18 23:08

#31

https://bbs.deepin.org/post/197314
ubuntu论坛上有人也说与内核有关，还说新版内核会解决，不知道发那帖子时是哪个版本内核
我也不敢贸然升 ...

升级内核又不会覆盖原来的内核，随时可以换回来，怕啥

Reply Like 0 View the author

SamLukeYes

deepin

2020-07-18 23:10

#32

https://bbs.deepin.org/post/197314
deepin应该没有使用baloo

deepin确实没有baloo，但是有deepin-anything

Reply Like 0 View the author

rekees2020

deepin

2020-07-18 23:17

#33

https://bbs.deepin.org/post/197314
升级内核又不会覆盖原来的内核，随时可以换回来，怕啥

自己升级内核后，deepin系统里自带的升级功能再推送不同版本的内核... 那不是凌乱了

Reply Like 0 View the author

SamLukeYes

deepin

2020-07-18 23:30

#34

本帖最后由 samlukeyes123 于 2020-7-18 16:03 编辑

https://bbs.deepin.org/post/197314
自己升级内核后，deepin系统里自带的升级功能再推送不同版本的内核... 那不是凌乱了 ...

grub在生成引导菜单的时候会将版本号最高的内核作为默认启动项，其他内核可以在高级选项中启动。如果你不想收到deepin推送的老版本内核的更新，可以卸载相应的元软件包。
PS：debian系推送内核更新的原理是用一个元软件包跟进内核版本，这个元软件包会依赖当前版本的内核的所有组件。当内核有更新时，元软件包会更新到新版本，同时依赖新版本的内核组件，不再依赖旧版本的组件，于是更新这个元软件包就会自动安装新版本的内核。新版本内核与旧版本内核之间不会冲突，确认新版本内核可用之后autoremove就可以卸载没有被依赖的旧内核。这种更新方式就避免了更新内核时直接覆盖旧内核，既防止了覆盖当前运行的内核可能出现的问题，也方便用户回到旧版本的内核。

Reply Like 0 View the author

xinaoshuijing

deepin

2020-07-18 23:41

#35

期待测试结果

Reply Like 0 View the author

rekees2020

deepin

2020-07-19 00:00

#36

https://bbs.deepin.org/post/197314
grub在生成引导菜单的时候会将版本号最高的内核作为默认启动项，其他内核可以在高级选项中启动。如果你不 ...

deepin是生产环境，我还不敢挑战这个难度的折腾，有空在虚拟机里先试试

Reply Like 0 View the author

mcaoser

deepin

2020-07-19 00:21

#37

复制文件为什么swap被使用？先关闭swap再试试看呢，用swapoff带参数关闭，swap使用肯定会影响其他应用对硬盘的使用

Reply Like 0 View the author

mcaoser

deepin

2020-07-19 00:27

#38

linux的cache和buffer，一个是读缓存，一个是写缓冲，通常是为下次读与本次写硬盘提供加速或缓冲功能的，使用的是空闲内存，不可能对复制有什么明显影响。这些通常称为脏数据

Reply Like 0 View the author

coslyk

deepin

2020-07-19 00:45

#39

有道理，我的Debian在Gnome Xorg下编译东西经常桌面就卡死了，但Gnome Wayland模式下就从来不会

Reply Like 0 View the author

mcaoser

deepin

2020-07-19 01:00

#40

另外还有一个可能就是如果是机械硬盘，大家都知道，在win下用软件测试硬盘时，会发现有些硬盘在使用久了后读写速率曲线的波动很大，就是有些硬盘块延迟很高了，而用mhdd测试硬盘会看到这种情况

Reply Like 0 View the author

2 / 5

Featured Collection

Change

New Thread

Popular Events