# Rebake 失败：如何诊断和修复？ **URL:** \ **Category:** Support\ **Created:** [2025年十一月19日 17:12 UTC](https://meta.discourse.org/t/rebake-failing-how-to-diagnose-and-fix/389064 "2025-11-19T17:12:14Z")\ **Posts on this page:** 1\ **Showing post:** 4
**Author:** ![Ed\_S](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/ed_s/32/134015_2.png) [@Ed\_S](https://meta.discourse.org/u/Ed_S)\ **Post date:** [2025年十二月14日 13:35 UTC](https://meta.discourse.org/t/rebake-failing-how-to-diagnose-and-fix/389064/4 "2025-12-14T13:35:13Z")
在重建期间的内存使用量远大于正常操作期间。看起来重新烘焙（rebaking）也会产生很大的需求。如果是这样，任何类型的定期监控都不会增加太多价值：监控需要在那些高峰期进行，而幸运的是，这些高峰期恰好发生在管理员执行某些特定操作时。 当我运行在较小、更边缘的机器配置上时，我会打开第二个终端窗口，通过 ssh 连接到我的服务器并运行 `vmstat 5` 它会记录内存使用量的起伏情况。观察 `swpd` 列并与您配置的交换空间进行比较。通常故障会突然发生，而不是逐渐发生，所以即使查看短期趋势也帮助不大。 如果您有足够的磁盘空间，拥有大量的交换空间是完全没有坏处的——可以是 RAM 的一半，甚至是与 RAM 一样多。它在这里是为了应对高峰。您不希望在正常使用期间看到交换/分页活动。同样，您可以使用 `vmstat 5 5` 来获取分页活动的短期快照（在 `si` 和 `so` 列中）。 这是一个例子： ```plaintext # 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`： ```plaintext # free total used free shared buff/cache available Mem: 1009140 696504 78544 51784 234092 118436 Swap: 2097144 154628 1942516 ``` 我们还看到当时我设法只用 1G RAM 运行 discourse。） --- _[View the full topic](https://meta.discourse.org/t/rebake-failing-how-to-diagnose-and-fix/389064)._