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

1 / 5

WangZhongyun

deepin

2020-07-18 03:30

从大范围到小范围地一个个试着排查，问题症结所在是会找到的。

Reply Like 0 View the author

六七八九十

deepin

2020-07-18 03:50

支持一下，希望找到真正的问题，linux桌面版复制文件感觉比win差很多，还有deepin文件管理器的复制进度条太不直观了

Reply Like 0 View the author

rekees2020

deepin

2020-07-18 03:54

切换到tty2开始复制，然后切换GUI的tty，继续做其他事情，这样是不是相当于拷贝不影响其他操作？只要从tty2切走的时候拷贝进程不中断
从tty2切回GUI的tty时，之前打开的东西都还在

Reply Like 0 View the author

蔡EEPIN

deepin

2020-07-18 03:54

不明觉厉，大佬

Reply Like 0 View the author

rekees2020

deepin

2020-07-18 04:01

测试过了，tty2下拷贝的时候切回GUI ，卡得非常yanyanzhong

Reply Like 0 View the author

thepoy

deepin

2020-07-18 04:26

昨天因为卡顿，内存低占用，cpu低占用，就是卡，一气之下把manjaro换成了mint，不知道还会不会卡。

Reply Like 0 View the author

牧野

deepin

2020-07-18 04:51

我想知道到底谁的锅？难道真的xorg？

Reply Like 0 View the author

SamLukeYes

deepin

2020-07-18 04:54

本帖最后由 samlukeyes123 于 2020-7-17 20:57 编辑

https://bbs.deepin.org/post/197314
昨天因为卡顿，内存低占用，cpu低占用，就是卡，一气之下把manjaro换成了mint，不知道还会不会卡。 ...

是KDE吗？如果是的话，禁用baloo试试。我以前用KDE的时候有时也会莫名其妙变卡，CPU和内存占用都不高，就是硬盘读写量巨大。禁用baloo以后仿佛整个世界都清静了

Reply Like 0 View the author

字甲达宾

deepin

2020-07-18 06:02

难道又是显卡驱动的锅？
A 卡，还是 N 卡？

Reply Like 0 View the author

peacekeep

deepin

2020-07-18 07:36

#10

nowave 发表于 2020-7-17 22:02
难道又是显卡驱动的锅？
A 卡，还是 N 卡？

都一样。应该不是显卡的事。抽空我再试下arm的。
另外，兄弟是中石油的嘛？太阳花头像。

Reply Like 0 View the author

peacekeep

deepin

2020-07-18 07:38

#11

rekees2020 发表于 2020-7-17 20:01
测试过了，tty2下拷贝的时候切回GUI ，卡得非常yanyanzhong

我这也一样，不管在哪里运行，桌面都会卡。而其他终端完全正常。

Reply Like 0 View the author

rekees2020

deepin

2020-07-18 16:58

#12

https://bbs.deepin.org/post/197314
我这也一样，不管在哪里运行，桌面都会卡。而其他终端完全正常。

那目前唯一的规避方法是，在一个非桌面终端拷文件的同时，去另外一个非桌面终端继续该干什么干什么
可是非桌面终端能干的事情太少，写代码、文字上网、看字符显示的视频...

Reply Like 0 View the author

SamLukeYes

deepin

2020-07-18 17:16

#13

https://bbs.deepin.org/post/197314
那目前唯一的规避方法是，在一个非桌面终端拷文件的同时，去另外一个非桌面终端继续该干什么干什么
可是 ...

好像有软件能在tty正常播放视频的，不是字符画的那种，不过我忘了叫啥了

Reply Like 0 View the author

ghostry

deepin

2020-07-18 17:32

#14

专业.

一级棒

Reply Like 0 View the author

rekees2020

deepin

2020-07-18 20:04

#15

多次测试后发现，基本不卡的方式只有用非安全WebDAV从本地拷到服务器，测试用文件大小为9.3GB，拷贝时其他程序基本感觉不到卡顿; 安全WwebDAV没测试
原因不明，不排除偶然因素

Reply Like 0 View the author

rekees2020

deepin

2020-07-18 20:25

#16

从服务器拷到本地，最不卡的是SMB，拷到80%左右时明显卡，100%时严重卡一阵，整个过程中大部分时间能小心地进行其他操作
从本地一个位置拷到另外一个位置，3%就开始卡，一直卡到结束，速度还不如局域网
基础功能卡成这样

不能够阿

Reply Like 0 View the author

ltree

deepin

2020-07-18 20:50

#17

我觉得还是内核配置的问题，因为linux在服务器上是没有硬件瓶颈的，而桌面硬件都有普遍的瓶颈，在设计的时候肯定哪里不太对，对比下安卓的内核配置也许会有收获

Reply Like 0 View the author

ltree

deepin

2020-07-18 20:51

#18

加油搞，搞出来请你吃deepin棒棒糖

Reply Like 0 View the author

rekees2020

deepin

2020-07-18 20:57

#19

ubuntu的论坛上找到的临时解决方案--
echo $((16*1024*1024)) > /proc/sys/vm/dirty_background_bytes
echo $((48*1024*1024)) > /proc/sys/vm/dirty_bytes
sudo提示无权限，只能su后执行
很多人说有效，但是我测试时无效

还有建议修改下面参数的--
vm.dirty_background_ratio = 5
vm.dirty_ratio = 10
这个我没测试，实在太折腾了，我对Linux又知之甚少，期待大神解决

Reply Like 0 View the author

ylxdxx

deepin

2020-07-18 21:03

#20

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

Reply Like 0 View the author

1 / 5

Featured Collection

Change

New Thread

Popular Events