¿La compilación está obteniendo/utilizando activos precompilados? ¿O has deshabilitado eso? (o modificado el núcleo de tal manera que los activos precompilados no se puedan usar)
Tiene mucha memoria de intercambio (swap), pero una gran parte ya está en uso. Como una configuración de dos contenedores tiene menos tiempo de inactividad, tal vez sea cierto que la invocación actual del servidor todavía se está ejecutando y ha acumulado un gran uso de memoria, quizás debido a una fuga.
Quizás un reinicio ayudaría, antes de la actualización. Quizás mida el uso de la memoria de intercambio antes y después del reinicio.
Tengo algún tipo de fuga/expansión de memoria en uno de mis servidores. Siguiendo la sensata sugerencia de @RGJ, programé un reinicio cada 7 días temprano el lunes por la mañana (hora de Europa Occidental) mediante cron.
(Creemos saber qué complemento tiene el problema, pero no he invertido tiempo en averiguar por qué hay una fuga/expansión de memoria).
Esto parece un OOM kill (terminación por falta de memoria): Tengo alrededor de ~2 GiB de RAM y en reconstrucciones de dos contenedores, la aplicación antigua + la nueva compilación se superponen y llevan la memoria al límite. El swap ya está usado en ~3 GiB antes del bootstrap, por lo que el pico de la compilación de Ember recibe una señal SIGKILL. Detener el contenedor en ejecución (o hacer una reconstrucción de un solo contenedor) evita la superposición y tiene éxito. El siguiente paso es confirmarlo a través de dmesg y luego reiniciar antes de las reconstrucciones / investigar qué está aumentando el swap con el tiempo / añadir RAM (el swap por sí solo no parece salvarlo una vez que ya está muy utilizado).
Esto parece menos un problema de pnpm o Ember y más que el host simplemente se está quedando sin memoria.
El detalle clave es la SIGKILL. Eso generalmente significa que el sistema operativo intervino y mató el proceso (a menudo a través del asesino OOM), no que ember build -prod falló por sí mismo.
En hosts pequeños, las compilaciones de producción de Ember pueden alcanzar fácilmente un par de GB de RAM. Incluso con el intercambio (swap) habilitado, una vez que el intercambio está mayormente utilizado, el kernel aún puede decidir matar un proceso node hambriento de memoria.
Algunas cosas que apuntan en esta dirección:
El intercambio ya se está utilizando mucho cuando ocurre el fallo.
El fallo es mucho más probable cuando otro contenedor se está ejecutando al mismo tiempo.
Si detengo el otro contenedor antes de ejecutar el arranque, la misma compilación tiene éxito.
Así que el intercambio ayuda un poco, pero principalmente solo retrasa el problema. Detener otros contenedores reduce la presión de memoria lo suficiente para que la compilación finalice.
Lo que ayudó / podría ayudar:
Evitar ejecutar múltiples arranques o compilaciones de activos en paralelo.
Detener otros contenedores durante ember build -prod.
Limitar el uso de memoria de Node (por ejemplo, NODE_OPTIONS=--max_old_space_size=1024) para reducir el uso máximo.
Si es posible, aumentar la RAM del host (4GB+) hace que esto sea mucho más confiable.
Espero que esto ayude a explicar por qué se siente un poco aleatorio y por qué detener otro contenedor hace que funcione.
Parece que más intercambio ayudaría. No haría daño. En lugar de mirar el intercambio total y decir que parece mucho, mire el intercambio libre y asegúrese de tener el margen para una reconstrucción.
¡Suena como una buena idea! ¿Reinicias el servidor o solo el contenedor?
De todos modos, me volvió a suceder en otro servidor de 2GB+3GB. Luego reinicié web_only y lo intenté de nuevo y funcionó perfectamente. Creo que añadiré a mis herramientas la opción de reiniciar web_only, quizás si la memoria está en alguna definición de “baja”.
Vimos un caso en el que reiniciar Linux ayudó. Sé que normalmente no es como nos gusta ver Linux, pero todavía existe la posibilidad de fragmentación y existe la posibilidad de fugas de memoria.
