为什么 vm.swappiness = 0 的 Ubuntu 服务器 20.04 仍然在有足够可用内存的地方进行交换？

Question

背景

我们在 Ubuntu 16.04 上运行多个 KVM 服务器，并已开始测试升级到 20.04。我们发现，尽管我们从未在 16.04 服务器上看到任何交换使用情况，但几天后，20.04 服务器将显示数百 MB 的交换使用情况。这不是一个大问题，因为 vmstat 显示交换活动非常少，并且 munin 图表确认交换输入/输出无关紧要，但我们仍然想了解这种行为。

到目前为止，我们已经使用 Nagios 来监视交换使用情况并在发现任何情况时发出警报。已从 16.04 升级到 20.04 的系统正在运行 5 个轻负载的 VM。主机系统显示已使用内存约 29G，总内存约为 200GB。没有峰值或任何导致内存使用量达到如此高的情况。VM 的内存使用受到限制，并且 KVM 服务器本身上没有运行其他占用内存的进程。

root@kvm-xx:~# free -m
              total        used        free      shared  buff/cache   available
Mem:         193336       29495         768           5      163072      162404
Swap:          6675         240        6435

顶部，进程交换的示例：

    PID    VIRT    RES    SHR S  %MEM COMMAND         SWAP 
   6447   18,2g  15,8g  22908 S   8,4 qemu-system-x86 239352 
   6160 2661052   1,9g  21880 S   1,0 qemu-system-x86  90788 
   6315 2129436 644388  21856 S   0,3 qemu-system-x86  29724 
   6391   10,4g   7,9g  22832 S   4,2 qemu-system-x86  24028 
   6197 6505584   3,0g  23008 S   1,6 qemu-system-x86  10972 
   5686    9908   2944   2720 S   0,0 cron                60
   5805   24404  14440   4388 S   0,0 munin-node           4 

vmstat 的典型输出，显示换入/换出没有变化。

root@kvm-xx:~# vmstat 2 10
procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
 0  0 407620 869916 214784 165081536    0    0   270    12    5    2  0  2 98  0  0
 2  0 407620 869900 214784 165081536    0    0     0    28 8533 24140  0  2 98  0  0
 1  0 407620 869836 214784 165081536    0    0     0    28 8642 24682  0  2 98  0  0

该系统在 16.04 上运行了一年，虚拟机和负载相同，交换量为 0。

已经尝试和测试过什么

升级后发现 numad 未安装，并且虚拟机未固定到同一物理 CPU 上的 vcpu。意思是numa节点上的内存使用情况。安装 numad 并验证固定。我相信在更改之前交换使用率较高，但不能肯定。

预计此行为与内核相关，因此从 5.4 升级到 HWE 5.11 内核。5.4 和 5.11 上的行为相同。

尝试禁用 KSM（内核同页合并），因为我们不需要它，并消除它作为交换使用的可能来源。

尝试完全禁用交换，看看是否存在真正的内存不足，导致 OOM 杀手出现。这没有发生，所以对我来说似乎不需要交换，但由于某种原因仍然被使用。

想法和想法

我相信，出于某种原因，即使 swappiness = 0，内核也会决定将不活动的页面换出进行交换。这可能是随 20.04 附带的新内核而改变的行为。

理想情况下，我们希望内核仅在最后手段时才进行交换，就像早期的行为一样，并使用交换使用情况监控来检测交换的使用情况并发出 Nagios 警报。

我一直在阅读有关类似主题的多个主题，但发现有关解释的信息相互矛盾。

我真正想避免的情况是，我们将一些负载较重的 16.04 服务器升级到 20.04，然后看到这个问题升级为生产中的真正问题。

我知道 swapoff / swapon on 手动将内存移出交换区，但问题是为什么它首先要交换。

如果有人对此有一些见解，将不胜感激。

谢谢！