问题/背景
我有一个（托管）Postgres 10.16 实例在 systemd-nspawn 容器中的 Fedora 32 上运行。我定期在指标中看到“系统”CPU 使用率大幅上升，这与 Postgres 查询吞吐量和磁盘活动的突然下降相关，持续时间从 30 秒到几分钟不等。我们的指标收集器还以不规则的时间间隔而不是每 10 秒收集一次。该问题大约每天发生一次。*
线索
上次发生这种情况时我运行了一些诊断程序并注意到在大部分低性能期间：
- kswapd 正在使用 100% 的核心
- 通过查看 的定期转储
/proc/vmstat，我注意到 的变化pgsteal_kswapd与 的变化之比pgscan_kswapd为 0.014。
也就是说，kswapd 似乎试图从页面缓存中回收页面，但对于它回收的每个页面，必须查看约 70 个页面。这个手册页表明低于 0.3 的比率值得关注。在其中一起事件的 50 秒时间内，kswapd 总共扫描了 230 万页，但仅回收了其中 32,000 页。
我怀疑这种病态的页面缓存回收行为与与之相关的性能问题有关。我还怀疑这可能与 postgres 在这里的容器中运行这一事实有关，a la这个类似但不相同的问题（不幸的是，我们无法改变这个决定，因为这取决于托管提供商）。但我不确定具体是什么导致了这种行为，或者如何找出根本原因或修复它。
问题
我有两个相关问题：
- 哪种类型的内存/磁盘访问模式可能导致回收效率如此低？
- 下次发生这种情况时我可以收集哪些信息，或者如何调试以缩小可能性空间？
附录：我考虑过并拒绝的假设
这本书给出了页面回收效率低的两个原因：
只有两种情况该算法可能表现得很糟糕。第一个是回收的候选者是否主要是匿名页面。在这种情况下，Linux 将在线性扫描进程页表以搜索要回收的页面之前不断检查大量页面，但幸运的是这种情况很少见。
我们/proc/meminfo同时转储，这表明很大一部分非活动页面是“文件”，而不是“匿名”（这对于 Postgres 来说是典型的，它建议将大部分机器内存分配给页面缓存）。所以我认为这不适用于我们。
第二种情况是，单个进程的 inactive_list 中有许多文件支持的常驻页面，这些页面经常被写入。进程和 kswapd 可能会进入不断“清洗”这些页面并将它们放在 inactive_list 顶部的循环，而不释放任何内容。在这种情况下，很少有页面从 active_list 移动到 inactive_list，因为两个列表大小之间的比率仍然没有显着变化。
根据 vmstat 转储，nr_dirtied事件期间仅增加了约 33k，而pgscan_kswapd增加了 2.3m。因此 kswapd 扫描页面的速度比写入页面的速度快得多，这也不是问题。
*目前还没有发生这种情况，因为我升级到了一个大量过度配置的实例，其核心数量增加了 50%，RAM 增加了 2 倍。