リビルド中は、通常の動作時よりもメモリ使用量がはるかに大きくなります。同様に、リベイク（rebaking）も大きな負荷をかけるようです。もしそうであれば、定期的な監視は何の価値もありません。監視が必要なのは、幸いにも管理者が特定のアクションを実行したときに発生するピーク時だからです。
より小さく、より限界的なマシンの構成で実行していた頃は、2つ目のターミナルウィンドウを開き、サーバーに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列が設定した2.0Gに対して1.5Gを超えてピークに達しているのがわかります。同じ5秒間のウィンドウでスワップアウト（so）アクティビティがピークに達し、次のウィンドウでスワップイン（si）がピークに達しているのがわかります。
（追記：以前にfreeを実行したため、2.0Gのスワップを設定していたことがわかります。
# free
total used free shared buff/cache available
Mem: 1009140 696504 78544 51784 234092 118436
Swap: 2097144 154628 1942516
この時点で、1GのRAMしかなくてもDiscourseを実行できていたこともわかります。）