中文 
rekees2020
deepin
2020-07-22 06:43 deepin https://bbs.deepin.org/post/197314
这个问题在终端服务上并不明显。主要还是桌面环境上有卡顿，试了安卓x86也有这个问题，个人猜测还是跟桌 ...
我拷大文件时，swap能到900多M，但是也不算大
如果终端上没有明显卡顿，应该如你所说，桌面相关组件影响I/O
Reply Like 0 View the author
#81
我拷大文件时，swap能到900多M，但是也不算大
如果终端上没有明显卡顿，应该如你所说，桌面相关组件影响I/O
peacekeep
deepin
2020-07-23 04:30 deepin https://bbs.deepin.org/post/197314
我拷大文件时，swap能到900多M，但是也不算大
如果终端上没有明显卡顿，应该如你所说，桌面相关组件影响I ...
5.4的内核好像已经修复这个问题。Ubuntu系的如此。UOS库里没有5.4的内核，没测试。deepin我没装，你可以试一下。
Reply Like 0 View the author
Please sign in first
刚刚看到有人说深度文件管理器在ntfs拷贝大文件会出现速度慢、系统卡死的情况。正好，我这两天刚刚测试了类似的问题：在linux各发行版下，大量磁盘操作后buffer/cache缓存过高，桌面卡死的情况。
首次发现这个问题是前两年编译aosp时，使用的系统时Ubuntu16.04。编译结束后，桌面直接卡死，无法操作。当时以为是系统过热的问题，毕竟是用的笔记本，直接强制关机了。后来多次出现同样的问题，感觉很奇怪，就用free -h查看了一下内存使用情况。结果显示内存 used 很正常1-2G左右吧，而free仅省了几百M，大量内存被buff/cache占用。
这个buff/cache是干什么的呢？详细的可以看一下下面这个博客。
简单说，就是读写磁盘的时候，内核会在内存中缓存磁盘的内容，便于以后读取方便，提高磁盘的I/O性能。内存将要耗尽的时候，内核又会回收这部分内存给其他进程使用。这样buff/cache缓存所占据的内存其实是可用内存。理论上，即使buff/cache占据了大部分的内存，也不会影响系统的稳定性。
不过，在linux桌面系统中，进行大量磁盘读写操作后，常见的就是拷贝大文件或者大量小文件，桌面就会卡死。使用下面3条任意一个释放buff/cache缓存后，均能改善。
测试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可以缓解卡顿。