Durante l’aggiornamento, di gran lunga la maggiore sollecitazione sulla memoria (RAM+swap) si verifica quando viene eseguito il processo ‘ember’. Penso che ogni volta che ho eseguito un aggiornamento, sia stato più grande del precedente, e si sta avvicinando al punto di non poter più funzionare su computer con dimensioni minime raccomandate.
Potrebbe essere utile esaminare questo aspetto prima che si verifichi effettivamente un guasto. (Speriamo che, per motivi di costo, la risposta non sia quella di aumentare la dimensione minima raccomandata. Aumentare lo swap aiuterebbe, se lo spazio su disco lo consente. In linea di principio, si potrebbe migrare temporaneamente a un’istanza più costosa con più RAM.)
Gestisco due forum di modeste dimensioni su istanze piccole, entrambe entro i minimi raccomandati, credo. In entrambi i casi, RAM+swap=3G. In un caso un’istanza Digital Ocean con 1G di RAM e 2G di swap, nell’altro caso un’istanza Hetzner con 2G di RAM e 1G di swap.
Ecco tre snapshot del processo ember, sulla macchina DO, utilizzando 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
Ovviamente la dimensione del processo di 43 GB non è interamente presente nella memoria virtuale, poiché abbiamo solo 3 GB disponibili. Utilizzare il 65% della dimensione della RAM per RSS è impressionante, ma di per sé non è un problema. La quantità di memoria libera e swap libero mostra che la macchina è vicina a una condizione di Out of Memory (OOM), che molto probabilmente comporterebbe l’uccisione di qualche processo e una conclusione disordinata dell’aggiornamento.
Ecco free come snapshot puntuale:
# free
total used free shared buff/cache available
Mem: 1009140 863552 72768 6224 72820 34868
Swap: 2097144 1160628 936516
Per cercare di catturare la situazione al suo punto più critico, ho usato 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
Noterai un gran numero di context switch (cs), molta attività del disco (bi, bo) e molta attività di swap (si, so), ma la cosa più importante è l’utilizzo dello swap fino a 1,6G con la memoria libera scesa a 60M e solo 54M di utilizzo dei buffer. Ciò significa che circa 2,6G dei 3G disponibili di memoria virtuale sono in uso. Si tratta dell’87% della capacità. (Potrebbe essere un po’ peggio, poiché stiamo campionando solo ogni 5 secondi.)
Si noti che la situazione era preoccupante (con circa 2G di utilizzo, quindi non così vicina al critico come oggi) quando ho aggiornato ad 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
