Durante la actualización, la mayor carga para la memoria (RAM+swap) se produce cuando se ejecuta el proceso ‘ember’. Creo que cada vez que he ejecutado una actualización, ha sido mayor que la anterior, y se está acercando a no poder ejecutarse en equipos con el tamaño mínimo recomendado.
Sería bueno investigar esto antes de que falle realmente. (Esperemos que, por razones de coste, la respuesta no sea aumentar el tamaño mínimo recomendado. Aumentar el swap ayudaría, si el espacio en disco lo permite. En principio, se podría migrar temporalmente a una instancia más cara con más RAM).
Ejecuto dos foros de tamaño modesto en instancias pequeñas, ambos dentro de los mínimos recomendados, creo. En ambos casos, RAM+swap=3G. En un caso, una instancia de Digital Ocean con 1G de RAM y 2G de swap, en el otro caso, una instancia de Hetzner con 2G de RAM y 1G de swap.
Aquí hay tres instantáneas del proceso ember, en la 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, el tamaño del proceso de 43 GB no está todo presente en la memoria virtual, ya que solo tenemos 3 GB disponibles. Usar el 65% del tamaño de la RAM para RSS es impresionante, pero no es un problema en sí mismo. La cantidad de memoria libre y swap libre muestra que la máquina está cerca de una condición de falta de memoria (OOM), lo que probablemente resultaría en que algún proceso sea eliminado y un final desordenado de la actualización.
Aquí está free como una instantánea puntual:
# free
total used free shared buff/cache available
Mem: 1009140 863552 72768 6224 72820 34868
Swap: 2097144 1160628 936516
Para intentar capturar la situación en su punto más cercano al fallo, usé 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
Notarás muchos cambios de contexto (cs), mucha actividad de disco (bi, bo) y mucha actividad de swap (si, so), pero lo más importante es el uso de swap hasta 1.6G con la memoria libre hasta 60M y solo 54M de uso de búfer. Esto significa que aproximadamente 2.6G de los 3G disponibles de memoria virtual están en uso. Eso es el 87% de la capacidad. (Podría ser un poco peor, ya que solo tomamos muestras cada 5 segundos).
Tenga en cuenta que la situación era preocupante (con aproximadamente 2G de uso, no tan cerca del punto crítico como hoy) cuando actualicé en 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
