Rebake schlägt fehl: wie diagnostizieren und beheben?

Der Speicherverbrauch ist während eines Rebuilds viel höher als im normalen Betrieb. Es scheint, dass auch das erneute Backen (rebaking) eine große Belastung darstellt. Wenn ja, würde eine regelmäßige Überwachung nicht viel Wert bringen: Die Überwachung wäre während dieser Spitzen erforderlich, die glücklicherweise dann auftreten, wenn der Administrator eine bestimmte Aktion ausführt.

Als ich auf einer kleineren, marginaleren Maschinenkonfiguration lief, hatte ich ein zweites Terminalfenster geöffnet, über SSH mit meinem Server verbunden und führte aus:
vmstat 5
was eine Aufzeichnung der Speichernutzung liefert, wie sie sich hebt und senkt. Beobachten Sie die Spalte swpd und vergleichen Sie sie mit Ihrem konfigurierten Swap-Speicher. Normalerweise tritt der Fehler plötzlich auf, nicht allmählich, sodass selbst die Betrachtung kurzfristiger Trends nicht viel hilft.

Wenn Sie über genügend Festplattenspeicher verfügen, schadet es überhaupt nicht, viel Swap zu haben – halb so viel wie RAM oder sogar so viel wie RAM. Er ist in diesem Fall da, um Spitzen abzufangen. Sie möchten während des normalen Gebrauchs keine Swap-/Paging-Aktivität sehen. Auch hier kann man vmstat 5 5 verwenden, um ein kurzfristiges Bild der Paging-Aktivität (in den Spalten si und so) zu erhalten.

Hier ist ein Beispiel:

# 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

Sie sehen, dass die Spalte swpd auf über 1,5G anstieg, gegenüber meinen konfigurierten 2,0G. Sie sehen, dass die Swap-Out-Aktivität (so) im selben 5-Sekunden-Fenster ihren Höhepunkt erreichte, und die Swap-In-Aktivität (si) im nächsten Fenster.

(Bearbeitung: Ich sehe, dass ich 2,0G Swap konfiguriert hatte, weil ich zuvor free ausgeführt hatte:

# free
              total        used        free      shared  buff/cache   available
Mem:        1009140      696504       78544       51784      234092      118436
Swap:       2097144      154628     1942516

Wir sehen auch, dass ich zu dieser Zeit Discourse mit nur 1G RAM betreiben konnte.)

1 „Gefällt mir“