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

4 / 5

SamLukeYes

deepin

2020-07-20 22:04

#61

https://bbs.deepin.org/post/197314
怎么禁用啊

https://wiki.archlinux.org/index.php/Baloo

Reply Like 0 View the author

神末shenmo

deepin

Spark-App

Q&A Team

2020-07-20 23:21

#62

https://bbs.deepin.org/post/197314
我用的是deepin v20，更新全部都装了，所有大文件复制操作，只要有本地硬盘参与读和/或写，一概卡顿，本 ...

应该是内核的问题

Reply Like 0 View the author

星辰使者

deepin

2020-07-20 23:51

#63

巨佬，你好！！！支持

Reply Like 0 View the author

Deepin Fans

deepin

2020-07-21 00:03

#64

这是真大佬！读了这篇文章恍然大悟。因为我是个Linux小白，最近使用deepin开发Android。用的是Android Studio，在编译的时候动不动就卡死，只能重启。原来是buffer/cache的锅。Android studio在编译的时候就会有大量的I/O操作。并且我给我的笔记本分配了swap，我一直以为是我的SSD有问题了，我还专门买了一块新的SSD回来，结果还是有这个问题。

Reply Like 0 View the author

deepin

2020-07-21 01:05

#65

8G内存或以上，我都不分配swap分区，看来不知不觉中避免了一种卡顿

Reply Like 0 View the author

rekees2020

deepin

2020-07-21 01:15

#66

https://bbs.deepin.org/post/197314
8G内存或以上，我都不分配swap分区，看来不知不觉中避免了一种卡顿

休眠对我来说是一种生产力工具，swap没了休眠就没了
另外，遇到有软件内存泄漏呢？有swap总能缓一下，勉强重启

Reply Like 0 View the author

rekees2020

deepin

2020-07-21 01:56

#67

https://bbs.deepin.org/post/197314
deepin确实没有baloo，但是有deepin-anything

测试过了，这口锅不属于deepin-anything，目前唯一有效的解决方式是关闭swap

Reply Like 0 View the author

rekees2020

deepin

2020-07-21 22:56

#68

刚才有人把几年前的软件顶出来
https://bbs.deepin.org/post/133470#
设置zswap完美解决问题，swap留住了，高I/O也不带来卡顿了
只是zram在deepin 20下设置无效

Reply Like 0 View the author

wnmer

deepin

2020-07-21 23:47

#69

https://bbs.deepin.org/post/197314
支持一下，希望找到真正的问题，linux桌面版复制文件感觉比win差很多，还有deepin文件管理器的复制进度条太 ...

我在实体机上安装的liux，表示在linux下从电脑copy文件到u盘，速度比在windows10下快。

Reply Like 0 View the author

wnmer

deepin

2020-07-21 23:48

#70

https://bbs.deepin.org/post/197314
好像有软件能在tty正常播放视频的，不是字符画的那种，不过我忘了叫啥了 ...

还有这种高科技，如果记起来，一定要告诉我。

Reply Like 0 View the author

wnmer

deepin

2020-07-21 23:52

#71

https://bbs.deepin.org/post/197314
怀疑过
8200M的swap分区，拷完文件时查看占用900多M
只知道怎么完全不用swap，但是不知道怎么部分停用， ...

swap是20年前内存过小的产物，现在内存都很大了，其实完全可以不需要swap分区了。但我不记得哪个linux的发行版还必须有swap分区，才能正常安装。

Reply Like 0 View the author

wnmer

deepin

2020-07-21 23:56

#72

https://bbs.deepin.org/post/197314
deepin是生产环境，我还不敢挑战这个难度的折腾，有空在虚拟机里先试试 ...

生产环境，建议还是用centos和freebsd，只安装自己需要的软件，不需要的一概不安装，毕竟稳定。

Reply Like 0 View the author

rekees2020

deepin

2020-07-22 00:01

#73

https://bbs.deepin.org/post/197314
swap是20年前内存过小的产物，现在内存都很大了，其实完全可以不需要swap分区了。但我不记得哪个linux的 ...

习惯用休眠了，swap关了就不能休眠

Reply Like 0 View the author

rekees2020

deepin

2020-07-22 00:06

#74

https://bbs.deepin.org/post/197314
生产环境，建议还是用centos和freebsd，只安装自己需要的软件，不需要的一概不安装，毕竟稳定。 ...

deepin用着顺手，不是非常折腾
15.xx在备用机器上只用过几次，主用机器直接上v20
目前遇到的严重问题就只是高I/O卡顿，已经比较完美地解决，这也不是deepin特有的问题，各发行版都一样
有全盘备份，乱了就直接恢复

Reply Like 0 View the author

peacekeep

deepin

2020-07-22 05:05

#75

https://bbs.deepin.org/post/197314
刚才有人把几年前的软件顶出来
https://bbs.deepin.org/post/133470#
设置z ...

试了一下，echo 1 > /sys/module/zswap/parameters/enabled后就不卡了。

Reply Like 0 View the author

rekees2020

deepin

2020-07-22 05:31

#76

https://bbs.deepin.org/post/197314
试了一下，echo 1 > /sys/module/zswap/parameters/enabled后就不卡了。

是的，zswap和zram任意开一个就有效
本质还是尽量避免swap到硬盘，改为swap到内存自然快

Reply Like 0 View the author

peacekeep

deepin

2020-07-22 05:46

#77

https://bbs.deepin.org/post/197314
是的，zswap和zram任意开一个就有效
本质还是尽量避免swap到硬盘，改为swap到内存自然快 ...

嗯。虽然没有解决根本的bug，但可以解决应用上的问题。

Reply Like 0 View the author

rekees2020

deepin

2020-07-22 05:55

#78

https://bbs.deepin.org/post/197314
嗯。虽然没有解决根本的bug，但可以解决应用上的问题。

根本的bug在于linux内核的swap机制，从内存swap到硬盘会带来大量I/O
zswap和zram有点像是掩耳盗铃，毕竟swap本来就是要省内存
不知道Windows的虚拟内存是怎么处理的，虚拟内存使用量大多数时候都大于0，但是复制文件从来不会卡
难道是更好的机制？也可能有类似zswap和zram的东西

Reply Like 0 View the author

Hello

deepin

2020-07-22 06:19

#79

一脸懵比。。。。但是这才是我想象中的科技论坛

建议置顶。。。。实在是太喜欢了。大佬们请继续讨论

Reply Like 0 View the author

peacekeep

deepin

2020-07-22 06:40

#80

https://bbs.deepin.org/post/197314
根本的bug在于linux内核的swap机制，从内存swap到硬盘会带来大量I/O
zswap和zram有点像是掩耳盗铃，毕竟s ...

这个问题在终端服务上并不明显。主要还是桌面环境上有卡顿，试了安卓x86也有这个问题，个人猜测还是跟桌面相关的组件有关，比如xorg、mesa什么的。其实swap使用量一直都不大，几十M而已。

Reply Like 0 View the author

4 / 5

Featured Collection

Change

New Thread

Popular Events