我相信我的交换/硬件/驱动程序发生了一些奇怪的事情。
我正在尝试将交换大小增加swapoff, lvresize，然后swapon再次增加。
当我这样做时swapoff /dev/swapdev，该命令花了 8 分 19 秒将大约 3.5GB 的交换页面移动到内存中。
在运行之前swapoff，我确保我的空闲 RAM 大于交换使用量，并且在运行时保持正确。
我有一台带有 SSD HDD 的 Intel Core i5 笔记本电脑。处理器之前不到 10% swapoff，而当我签入时，swapoff正在使用 70%+ CPU。
一直以来，杂志上都没有什么有趣的东西。
以下是我预计将 3.5G 从磁盘分流到内存所需的时间：
$ time dd if=/dev/urandom of=/tmp/del bs=1M count=3500
3500+0 records in
3500+0 records out
3670016000 bytes (3.7 GB, 3.4 GiB) copied, 23.7288 s, 155 MB/s
real 0m24.789s
user 0m0.000s
sys 0m22.743s
我在跑 Linux svelte 4.9.53-1-MANJARO #1 SMP PREEMPT Thu Oct 5 15:11:15 UTC 2017 x86_64 GNU/Linux
命令需要这么长时间的任何原因？这可能是一个更大问题的一部分，但这是我可以明确指出的第一件事，看起来很奇怪。
小智 12
你错过了 swapoff 真正的作用。
在正在交换的正在运行的机器上停用交换空间非常复杂。8 分钟内的 3.5G 速度可能非常快 + 按预期工作。
运行 swapoff 不仅仅是将代码从磁盘移到内存中。
一旦你交换......好吧......你正在交换，这意味着你的操作系统内存不足+你有磁盘i/o到你的交换设备+磁盘i/o到你的其他文件系统+甚至可能如果涉及看门狗或 systemd 自动重启，OOM（内存不足杀手）开始运行 + 然后处理 OOM 进程的颠簸重新启动。
如果您的系统正在交换，这意味着交换是唯一使您的系统保持活动状态的方法。
如果你杀死交换空间，那么你的系统就不能再使用交换空间，所以现在你的操作系统必须加载普通文件系统的代码 + 当内存耗尽时驱逐代码 + 然后而不是通过优化的原始磁盘从快速交换空间中提取代码读取，您的所有代码都必须脱离正常的文件系统，并进行目录遍历。这比从交换空间中拉出的资源要密集得多。
当你在一个正在交换的系统上进行交换时......通常你最终会遇到这个过程需要几个小时+有时机器会崩溃的情况。
如果您出于某种原因必须停用交换设备，最好先创建一个辅助的、基于文件系统的交换空间 + 为这个新的交换空间进行交换，然后在旧的交换设备上进行交换。
如果您采用这种方法，您的系统将永远存在。