Durante a atualização, a maior sobrecarga de memória (RAM+swap) ocorre quando o processo ‘ember’ é executado. Acho que cada vez que executei uma atualização, ela foi maior do que antes, e está chegando perto de não conseguir ser executada em computadores com o tamanho mínimo recomendado.
Pode ser bom investigar isso antes que realmente falhe. (Esperançosamente, por razões de custo, a resposta não será aumentar o tamanho mínimo recomendado. Aumentar o swap ajudaria, se o espaço em disco permitir. Em princípio, poder-se-ia migrar temporariamente para uma instância maior com mais RAM, mais cara.)
Eu executo dois fóruns de tamanho modesto em instâncias pequenas - ambos dentro dos mínimos recomendados, acredito. Em ambos os casos, RAM+swap=3G. Em um caso, uma instância Digital Ocean com 1G de RAM e 2G de swap, no outro caso, uma instância Hetzner com 2G de RAM e 1G de swap.
Aqui estão três instantâneos do processo ember, na máquina DO, usando 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
Obviamente, os 43 GB de tamanho do processo não estão todos presentes na memória virtual, pois temos apenas 3 GB disponíveis. Usar 65% do tamanho da RAM para RSS é impressionante, mas não é um problema em si. A quantidade de memória livre e swap livre mostra que a máquina está perto de uma condição de falta de memória (OOM), o que provavelmente resultaria em algum processo sendo encerrado e um fim desorganizado para a atualização.
Aqui está free como um instantâneo em um determinado momento:
# free
total used free shared buff/cache available
Mem: 1009140 863552 72768 6224 72820 34868
Swap: 2097144 1160628 936516
Para tentar capturar a situação mais próxima da falha, usei 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
Você notará muitas trocas de contexto (cs), muita atividade de disco (bi, bo) e muita atividade de swap (si, so), mas o mais importante é o uso de swap de até 1,6G com a memória livre caindo para 60M e apenas 54M de uso de buffer. Isso significa que cerca de 2,6G dos 3G disponíveis de memória virtual estão em uso. Isso é 87% da capacidade. (Pode ser um pouco pior, pois estamos amostrando apenas a cada 5 segundos.)
Note que a situação era preocupante (com cerca de 2G usados, não tão perto do crítico quanto hoje) quando atualizei em agosto:
# 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
