Während des Upgrades ist die bei weitem größte Belastung für den Speicher (RAM+Swap), wenn der Prozess ‘ember’ läuft. Ich glaube, jedes Mal, wenn ich ein Update durchgeführt habe, war es größer als zuvor, und es nähert sich der Unfähigkeit, auf Computern mit der empfohlenen Mindestgröße zu laufen.
Es wäre gut, dies zu untersuchen, bevor es tatsächlich fehlschlägt. (Hoffentlich wird die Antwort aus Kostengründen nicht lauten, die empfohlene Mindestgröße zu erhöhen. Eine Erhöhung des Swaps würde helfen, wenn genügend Speicherplatz vorhanden ist. Grundsätzlich könnte man vorübergehend zu einer teureren Instanz mit mehr RAM wechseln.)
Ich betreibe zwei Foren von moderater Größe auf kleinen Instanzen - beide liegen meiner Meinung nach innerhalb der empfohlenen Mindestwerte. In beiden Fällen beträgt RAM+Swap=3G. In einem Fall eine Digital Ocean-Instanz mit 1G RAM und 2G Swap, in dem anderen Fall eine Hetzner-Instanz mit 2G RAM und 1G Swap.
Hier sind drei Momentaufnahmen des Ember-Prozesses auf der DO-Maschine, die ps auxc verwenden.
USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
1000 10342 87.7 65.1 32930460 657936 ? Rl 16:57 2:23 ember
USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
1000 10342 84.9 60.7 43572204 612668 ? Rl 16:57 2:57 ember
USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
1000 10342 81.2 55.2 43405220 557128 ? Rl 16:57 3:40 ember
Offensichtlich sind die 43 GB Prozessgröße nicht vollständig im virtuellen Speicher vorhanden, da wir nur 3 GB zur Verfügung haben. 65 % der RAM-Größe für RSS zu verwenden, ist beeindruckend, aber an sich kein Problem. Die Menge an freiem Speicher und freiem Swap zeigt, dass die Maschine nahe an einem Out-of-Memory (OOM)-Zustand ist, was höchstwahrscheinlich dazu führen würde, dass ein Prozess beendet wird und das Update unsauber endet.
Hier ist free als Momentaufnahme:
# free
total used free shared buff/cache available
Mem: 1009140 863552 72768 6224 72820 34868
Swap: 2097144 1160628 936516
Um die Situation am Rande des Scheiterns zu erfassen, habe ich vmstat 5 verwendet.
# 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 werden viele Kontextwechsel (cs), viel Festplattenaktivität (bi, bo) und viel Swap-Aktivität (si, so) bemerken, aber das Wichtigste ist die Swap-Nutzung bis zu 1,6 G, während der freie Speicher auf 60 M und die Puffer auf nur 54 M reduziert ist. Das bedeutet, dass etwa 2,6 G der verfügbaren 3 G virtuellen Speichers belegt sind. Das sind 87 % der Kapazität. (Es könnte etwas schlimmer sein, da wir nur alle 5 Sekunden abfragen.)
Beachten Sie, dass die Situation besorgniserregend war (ca. 2 G belegt, also bei weitem nicht so kritisch wie heute), als ich im August ein Update durchführte:
# 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 700404 62740 1956 48748 35 29 108 92 3 8 2 1 96 0 1
1 0 741000 65996 1880 44360 3708 11190 3982 11191 643 1437 92 4 0 3 1
1 0 834836 70452 1480 53856 528 18969 4274 18974 532 1575 93 6 0 1 0
4 1 1010144 82192 4644 44400 30065 38803 35455 39946 4432 19267 28 26 0 39 7
1 0 644116 307764 1644 55348 24406 21154 27724 21945 2551 8672 52 22 0 21 6
