问题描述
多年以来，我的小型Ubuntu配置一直遇到相同的问题：所使用的交换空间随时间增加。我的印象是，这主要是因为分配的内存即使有足够的空间也永远不会返回RAM，除非用户操作(如禁用交换)。
我做了一个简短的cron命令来使它自动化，并且我得到了很好的结果：
#! /bin/sh
echo "* */1 * * * root swapoff -a && swapon -a" >> /etc/crontab
但是，由于这不是真正解决该问题的技巧，所以我想知道它可能不是一个好主意的潜在原因，或者我该如何改进此脚本以使其更聪明？
最佳思路
这样使用：是的，不好。在关闭交换之前，您确实需要检查是否有足够的可用内存。有关更好的版本，请参见https://askubuntu.com/a/90399/15811。
另外：您确定吗？分配交换并不意味着正在使用交换。命令vmstat，列si(交换)和so(交换)。如果这些值仍然为0，则会出现另一个问题。根据我的经验，几乎不使用交换，并且您可能不会使用它，因为它不会清空它，但是没有什么可清空的。
次佳思路
我会说这是一个坏主意。如果您认为自己有可用内存，并且没有将活动进程从交换位置移到RAM，那么您要么没有如您想像的那样多的空闲内存，要么该进程没有您想象的那么活跃是。
如果活动进程继续被交换，则应修复造成内存压力的任何原因。如果这不是一个积极的过程，那有什么大不了的？
第三种思路
这是一个坏主意。
内核开始复制(不移动)数据以进行交换，直到物理内存快要用完为止，因为如果某个进程需要大量内存，那么任何已经在交换中具有有效副本的页面都可以立即被重用，而无需再次写入到磁盘。
通常，这种情况主要发生在长时间未访问的页面上，这很好地表明了不太可能很快访问它们。
如果显式丢弃副本，则不会带来任何好处，因为数据仍然存在于RAM中，但是当某些进程想要分配大量内存并需要进行交换时，可能会降低速度。
一旦物理内存已满50％以上，内核也将始终使用交换空间，因此即使您安装了足够的内存，这些数字也将不为零。
第四种思路
这是一个坏主意。如果有用，Linux内核将以这种方式实现。我认为没有理由要更改许多调整参数，因为这样一个简单的shell脚本很可能并不比内核开发人员的算法更聪明。
您基本上有两种情况：
-
交换空间中的进程始终不使用。为什么要将它们拉回RAM？
-
RAM很少，因此它们被换出，然后将它们拉回到RAM中。然后，系统将尽快将它们重新置于交换状态。
因此，有两个要点：
-
首先，如果RAM太少而无法一次运行所有程序，则系统速度将会很慢。交换将帮助您运行更多程序，但不能快速切换到很少使用的程序，后者可能会被交换掉。任何交换都不会杀死很少使用的交换机，也不会向当前使用的交换机发送out-of-memory异常。
-
其次，交换是一件好事，交换中也是有好处的，因为您有可用的RAM，但要以当前不使用的程序为代价。
尽管使用太多程序没有出现out-of-memory问题，但是某些程序可能会基于当前可用的RAM分配内存(也许您的浏览器将使用更多的内存缓存，并且您可以浏览得更快)，并且内核可以使用可用的RAM进行磁盘缓存和类似的优化。当您强制交换为空时，内核将删除其读取缓存，例如启动新的Firefox实例所需的时间将比Firefox仍在磁盘缓存中的时间长。
如果要调整内核的行为，请参见swappiness parameter。
@ peter-cordes提供了另外两个资源：
如果您确实要清空交换，可以永久关闭交换。我不明白为什么将其打开一个小时然后将其清空比没有交换有优势。
第五种思路
通过告诉内核释放缓存，可以达到相同的结果：
echo 3 > /proc/sys/vm/drop_caches
这样，您就避免了可能出现内存不足的短暂时刻，并让内核来决定什么是必要的以及哪些可以被丢弃。