Lors de la mise à niveau, la plus grande contrainte sur la mémoire (RAM+swap) est de loin lorsque le processus ‘ember’ s’exécute. Je pense que chaque fois que j’ai effectué une mise à jour, elle a été plus importante que la précédente, et elle approche de la limite, rendant impossible son exécution sur des ordinateurs de taille recommandée minimale.
Il serait peut-être bon d’examiner cela avant que cela ne échoue réellement. (J’espère que, pour des raisons de coût, la réponse ne sera pas d’augmenter la taille minimale recommandée. Augmenter le swap aiderait, si l’espace disque le permet. En principe, on pourrait migrer temporairement vers une instance plus coûteuse avec plus de RAM.)
J’exécute deux forums de taille modeste sur de petites instances - tous deux dans les minimums recommandés, je crois. Dans les deux cas, RAM+swap=3G. Dans un cas, une instance Digital Ocean avec 1G de RAM et 2G de swap, dans l’autre cas, une instance Hetzner avec 2G de RAM et 1G de swap.
Voici trois instantanés du processus ember, sur la machine DO, en utilisant ps auxc
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
Évidemment, la taille de processus de 43 Go n’est pas entièrement présente en mémoire virtuelle car nous n’avons que 3 Go disponibles. Utiliser 65 % de la taille de la RAM pour le RSS est impressionnant, mais pas en soi un problème. La quantité de mémoire libre et de swap libre montre que la machine est proche d’une condition de manque de mémoire (OOM), ce qui entraînerait très probablement la suppression d’un processus et une fin peu ordonnée de la mise à jour.
Voici free comme instantané à un moment donné :
# free
total used free shared buff/cache available
Mem: 1009140 863552 72768 6224 72820 34868
Swap: 2097144 1160628 936516
Pour essayer de capturer la situation au plus près de l’échec, j’ai utilisé vmstat 5
# 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
Vous remarquerez beaucoup de commutations de contexte (cs), beaucoup d’activité disque (bi, bo) et beaucoup d’activité de swap (si, so), mais le plus important est l’utilisation du swap jusqu’à 1,6 Go avec la mémoire libre descendant à 60 Mo et seulement 54 Mo d’utilisation de buffer. Cela signifie qu’environ 2,6 Go des 3 Go de mémoire virtuelle disponibles sont utilisés. C’est 87 % de la capacité. (Cela pourrait être un peu pire, car nous échantillonnons seulement toutes les 5 secondes.)
Notez que la situation était préoccupante (environ 2 Go utilisés, donc pas aussi proche de la critique qu’aujourd’hui) lorsque j’ai mis à jour en août :
# 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
