我有一台 8GB RAM 的 Linux 机器，上面运行着 4 个 tomcat 服务器。其中一个设置为 3000MB 内存（jvm -Xms 和 -Xmx 设置），其他设置为 1500MB。交换分区也设置为 8Gigs。当我启动这些服务器时，交换文件使用率很低。但在几天内以及在某个时间，当一台/所有服务器处于高峰活动时，交换使用率开始增加。以下是典型的 sar -r 输出。
kbmemfree kbmemused %memused kbbuffers kbcached kbswpfree kbswpused %swpused 韓國
48260 8125832 99.41 196440 2761852 7197688 1190912 14.20 316044
75504 8098588 99.08 198032 2399460 7197688 1190912 14.20 316032
它显示当前已使用 14.2% 的交换。有趣的是，这个百分比永远不会减少。它继续增加并达到 30-40%。我们每周重启一次服务器。
我认为%swpused在高峰活动期间增加，在低活动期间减少。或者至少保持不变。这看起来交换空间从未被操作系统回收。
释放的输出：free -m 总使用的空闲共享缓冲区缓存内存：7982 7937 45 0 32 2088 -/+ 缓冲区/缓存：5816 2166 交换：8191 1163 7028
因此至少有 2g 的可用内存。所以问题是为什么交换空间不断增加并且没有被操作系统回收？或者如何调试以找出发生了什么。
答案1
如果信息被交换到磁盘，然后又读回到内存中，那么它通常会被保留在交换区域中，直到交换空间不足为止。这意味着，如果相同的信息稍后需要再次交换出来并且没有改变，那么操作系统可以直接从分配的 RAM 中删除页面，而无需将任何内容写入磁盘，从而节省时间。
分配给已读回内存的内容的交换将被释放
- 当相关页面不再需要时（即被应用程序释放）
- 当相关页面发生更改时（因此磁盘上的副本不再是最新的）
- 机器的交换空间不足，因此清除 RAM 中已有的某些内容以腾出空间
查找/proc/meminfo名为“SwapCached”的行。此条目统计在 RAM 和交换分区中找到的页面。例如，随机挑选一个小型 VM，/proc/meminfo我的一个 VM 显示的虚拟文件为：
SwapTotal: 698816 kB
SwapFree: 624520 kB
SwapCached: 17232 kB
表示已分配 74268K 的交换空间，但其中 17232K 的页面当前也已映射到 RAM 中（因此，如果其他东西需要该空间，则可以随时从交换中释放该空间）。
此外，毫无疑问，那里会有一些很久以前就被换出的页面，从那以后再也没有使用过。内核不会仅仅因为有一些空闲的 RAM 可以将其读回而重新加载交换中的页面，因为这些空闲的 RAM 可能更适合用作缓存或缓冲区 - 写入交换的页面通常只会在下次需要时重新读取。
如果您想清除交换中的内容，只要您有足够的空闲和/或可释放空间（即空闲+缓存+缓冲区（减去 c+b 计数中不可释放的部分 RightThisInstant）），只需将其关闭然后重新打开swapoff -a && swapon -a。
当然，您也可能在某处发生内存泄漏，但这并不是您所看到的行为的唯一解释。
答案2
基本上，您不需要关心这一点。重要的是要知道有多少 IO 进入了交换区（查看“vmstat”命令）。在交换区中增加更多内容不会产生任何成本。唯一的成本是将内容放入交换区（页面输入）或将其取出（页面输出）。因此，操作系统让交换区增大是完全合理的。
答案3
只要您有可用的交换空间，操作系统就无需释放交换空间。当没有剩余空间时，它将被释放。但是当您遇到这种情况时，您肯定会遇到问题。
答案4
除非您运行服务器足够长的时间来查看它是否会成为一个问题，否则无法判断这是否最终会成为一个问题。
基本上，操作系统会交换未使用的内容，以始终保持一些内存可用，以防新程序启动。交换空间只有在需要时才会释放，这意味着您可以 100% 使用交换空间，而不会出现性能问题。需要担心的是这是否是由内存泄漏引起的。这不一定是内存泄漏，但可能是。
Java 不容易发生内存泄漏，但在复杂的应用程序中尤其可能发生。