在重建期间的内存使用量远大于正常操作期间。看起来重新烘焙（rebaking）也会产生很大的需求。如果是这样，任何类型的定期监控都不会增加太多价值：监控需要在那些高峰期进行，而幸运的是，这些高峰期恰好发生在管理员执行某些特定操作时。
当我运行在较小、更边缘的机器配置上时，我会打开第二个终端窗口，通过 ssh 连接到我的服务器并运行
vmstat 5
它会记录内存使用量的起伏情况。观察 swpd 列并与您配置的交换空间进行比较。通常故障会突然发生，而不是逐渐发生，所以即使查看短期趋势也帮助不大。
如果您有足够的磁盘空间，拥有大量的交换空间是完全没有坏处的——可以是 RAM 的一半，甚至是与 RAM 一样多。它在这里是为了应对高峰。您不希望在正常使用期间看到交换/分页活动。同样，您可以使用 vmstat 5 5 来获取分页活动的短期快照（在 si 和 so 列中）。
这是一个例子：
# vmstat 5 5
procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
r b swpd free buff cache si so bi bo in cs us sy id wa st
3 0 1392140 61200 11632 76432 41 32 117 93 0 1 2 1 97 0 0
1 1 1467220 63416 324 67284 8786 20499 13178 20567 2539 8924 77 13 0 10 0
0 2 1593340 57916 1096 53832 24262 46868 29986 46889 5377 18534 44 22 0 34 0
4 0 1155632 120680 2772 86280 39111 35424 54768 37824 6987 25174 38 27 0 35 0
3 0 1102988 74096 2852 85276 11261 246 12610 271 1879 6365 86 6 0 8 0
您可以看到 swpd 列的峰值超过了 1.5G，而我配置的是 2.0G。您可以看到交换出（so）活动在同一 5 秒窗口内达到峰值，而交换入（si）活动在下一个窗口达到峰值。
（编辑：我可以看到我配置了 2.0G 交换空间，因为我之前运行了 free：
# free
total used free shared buff/cache available
Mem: 1009140 696504 78544 51784 234092 118436
Swap: 2097144 154628 1942516
我们还看到当时我设法只用 1G RAM 运行 discourse。）