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

         刚刚看到有人说深度文件管理器在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缓存后，均能改善。         因此当时一直认为是内存不足导致的卡顿，也没多想。这几天拷贝文件时又遇见了这个问题，就想着如何调整内核参数限制buffer/cache。
        实际上，多次调整并没有改善大量文件拷贝过程中出现的卡顿问题。但在调整过程发现，卡顿出现的时间点跟缓存释放，buff/cache降低，free增加的时间点基本吻合。导致卡顿的问题可能不是内存太小，而是buff/cache释放的过程。为此，使用如下脚本（drop_caches.sh）进行了测试：        用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可以缓解卡顿。