La actualización de 3.2.0.beta3-dev a 3.2.0.beta3 falló debido a falta de memoria

Instalación
1

Hola,

Intenté actualizar desde 3.2.0.beta3-dev a 3.2.0.beta3 siguiendo las indicaciones y mi instancia de Discourse se rompió debido a falta de memoria durante la compilación de assets de ember. Intenté ./launcher rebuild app con el mismo resultado.

FATAL ERROR: Reached heap limit Allocation failed - JavaScript heap out of memory
 1: 0xb83f50 node::Abort() [ember]
 2: 0xa94834  [ember]
 3: 0xd647c0 v8::Utils::ReportOOMFailure(v8::internal::Isolate*, char const*, bool) [ember]
 4: 0xd64b67 v8::internal::V8::FatalProcessOutOfMemory(v8::internal::Isolate*, char const*, bool) [ember]
 5: 0xf42265  [ember]
 6: 0xf5474d v8::internal::Heap::CollectGarbage(v8::internal::AllocationSpace, v8::internal::GarbageCollectionReason, v8::GCCallbackFlags) [ember]
 7: 0xf2ee4e v8::internal::HeapAllocator::AllocateRawWithLightRetrySlowPath(int, v8::internal::AllocationType, v8::internal::AllocationOrigin, v8::internal::AllocationAlignment) [ember]
 8: 0xf30217 v8::internal::HeapAllocator::AllocateRawWithRetryOrFailSlowPath(int, v8::internal::AllocationType, v8::internal::AllocationOrigin, v8::internal::AllocationAlignment) [ember]
 9: 0xf113ea v8::internal::Factory::NewFillerObject(int, v8::internal::AllocationAlignment, v8::internal::AllocationType, v8::internal::AllocationOrigin) [ember]
10: 0x12d674f v8::internal::Runtime_AllocateInYoungGeneration(int, unsigned long*, v8::internal::Isolate*) [ember]
11: 0x17035b9  [ember]
Aborted (core dumped)
error Command failed with exit code 134.
I, [2023-11-26T17:19:26.345389 #1]  INFO -- : yarn run v1.22.19
$ /var/www/discourse/app/assets/javascripts/node_modules/.bin/ember build
Environment: development
WARNING: ember-test-selectors: You are using an unsupported ember-cli-babel version. data-test properties are not automatically stripped from your JS code.
info Visit https://yarnpkg.com/en/docs/cli/run for documentation about this command.

Estoy ejecutando en una instancia de DigitalOcean con 1GB para una organización sin fines de lucro, por lo que no puedo permitirme redimensionarla con más memoria. 1GB es el tamaño mínimo para Discourse y las versiones anteriores solían funcionar sin problemas. ¿Alguna idea sobre cómo hacer que vuelva a funcionar?

2

¿Tienes Swap?

¿Cuál es la salida de

free -h
1 me gusta
3 
               total        used        free      shared  buff/cache   available
Mem:           952Mi       321Mi       414Mi       3.1Mi       374Mi       631Mi
Swap:          2.0Gi        75Mi       1.9Gi
4

Solo necesitarías redimensionarlo durante la reconstrucción.

2 Me gusta
5

Quizás quieras considerar mudarte a Hetzner, que ofrece precios competitivos y 2 GB de RAM en su plan básico.

1 me gusta
6

Hola y bienvenido @andreid :slight_smile:

Mi sitio de prueba DO de 1 GB también ha estado experimentando problemas de memoria durante las reconstrucciones recientemente. Temporalmente lo actualicé a 2 GB solo para sacarlo adelante.

1 me gusta
7

¿Quizás valdría la pena actualizar ahora los requisitos mínimos en la documentación a 2 GB de RAM?

2 Me gusta
9

Recuerdo que sucedió el año pasado y se hicieron algunos ajustes JavaScript heap out of memory due to Ember CLI - #4 by JammyDodger. No estoy seguro de si se puede hacer algo esta vez también, pero preguntaré. :+1:

3 Me gusta
10

Gracias @RGJ y @JammyDodger, cambiar el tamaño temporalmente funcionó.

3 Me gusta
11

Agregar 1G de swap debería ser funcionalmente lo mismo que agregar 1G de RAM, si tienes espacio en disco para hacerlo. (Probablemente tardará más en ejecutar la actualización, pero eso es rendimiento, en lugar de función. Lo que deseas es evitar la situación de falta de memoria).

13

Tengo información adicional en caso de que ayude a mitigar el problema desde el lado de Discourse. Mi instancia (DigitalOcean ~1GB droplet con 2GB de swap) recientemente comenzó a tardar significativamente más en reconstruirse y a reportar el mismo error fatal aproximadamente 3 de cada 4 veces (la suerte parece mejorar después de ejecutar ./launcher cleanup, pero no tengo suficiente tamaño de muestra para confirmarlo).

Poco antes del error de falta de memoria heap, se registran estas líneas:

Node.js heap_size_limit (491.0) is less than 1024MB. Setting --max-old-space-size=1024.
Node.js heap_size_limit (491.0) is less than 2048MB. Disabling Webpack parallelization with JOBS=0 to conserve memory.

Estoy fuera de mi dominio aquí, así que me disculpo si digo algo incorrecto. Una investigación rápida indica que ember-cli depende de node.js, que es por lo que creo que esto es relevante. El flag --max-old-space-size puede ser configurado más alto que la RAM (simplemente iría al espacio de swap, lo cual como se mencionó está bien para este caso), así que quizás 1024 es un techo artificial que estamos golpeando contra el cual las reconstrucciones de Discourse ya no pueden ser contenidas.

Notas al margen: aparentemente --optimize-for-size es un flag de node.js que ayuda a reducir el uso de memoria (no estoy seguro si es utilizado por Discourse/ember, quizás ya lo es), y hay una anécdota por ahí de que el recolector de basura no está activado para ciertos usos de node.js, lo cual podría ser un problema.

Si algo de esto es relevante y controlable desde el lado de Discourse del uso de ember/node.js, podría valer la pena que alguien lo investigue. Si no, no se preocupen, aplicaré la solución temporal de actualización a 2GB propuesta anteriormente. :slight_smile:

1 me gusta
14

¡Ese es un muy buen punto! Ahora lo aumentamos a 1024 MB en máquinas con poca RAM aquí. Ciertamente podríamos experimentar aumentando eso a 1500 o 2000 y ver si ayuda.

Si tienes tiempo/inclinación para probarlo tú mismo, podrías configurarlo agregando una nueva variable a la sección env: de tu archivo app.yml:

Editar: :warning: este es ahora el valor predeterminado de Discourse. No es necesario configurarlo tú mismo

  NODE_OPTIONS: "--max-old-space-size=2048"
3 Me gusta
15

¡Ah, perfecto! Lo he probado.

Dado que el error fatal no ocurre siempre y una reconstrucción tarda unos 25 minutos últimamente (en comparación con los 5-10 anteriores), puede que pase un tiempo antes de que sepa si aumentar ese número resuelve el problema de memoria para estas especificaciones de servidor.

Sin embargo, ya puedo confirmar que las dos advertencias de Node.js heap_size_limit ya no aparecen en el registro de reconstrucción, y mi primera reconstrucción fue exitosa, así que eso es prometedor.

EDITADO: He podido reconstruir varias veces sin problemas, gracias a la configuración NODE_OPTIONS anterior en mi app.yml. ¡Genial!

EDITADO2: Esta solución probablemente debería incorporarse a Discourse aumentando ese número mágico (enlace de la publicación de David) para que otras máquinas con poca RAM puedan seguir funcionando. Si alguien lee esto y sabe cómo hacerlo, sería genial. :slight_smile:

2 Me gusta
16

Nosotros también nos encontramos con esto en https://caddy.community.

Ejecutamos ./launcher rebuild app varias veces y falló con varios problemas.
Primero tuvimos problemas con bundle install que se quejaba de rbtrace (terminando con An error occurred while installing rbtrace (0.5.0), and Bundler cannot continue.)

Luego, eventualmente, tuvimos este problema de OOM:

I, [2023-12-12T07:50:59.497921 #1]  INFO -- : > cd /var/www/discourse & su discourse -c 'bundle exec rake themes:update assets:precompile'
Node.js heap_size_limit (1010.0) is less than 1024MB. Setting --max-old-space-size=1024.
Node.js heap_size_limit (1010.0) is less than 2048MB. Disabling Webpack parallelization with JOBS=0 to conserve memory.

<--- Last few GCs --->

[3683:0x5dab130]   279104 ms: Scavenge 981.3 (1037.1) -> 974.5 (1037.1) MB, 8.3 / 0.0 ms  (average mu = 0.699, current mu = 0.681) allocation failure; 
[3683:0x5dab130]   279136 ms: Scavenge 981.8 (1037.1) -> 975.0 (1037.1) MB, 8.0 / 0.0 ms  (average mu = 0.699, current mu = 0.681) allocation failure; 
[3683:0x5dab130]   282606 ms: Mark-sweep 994.8 (1050.6) -> 987.7 (1048.9) MB, 3316.1 / 0.0 ms  (average mu = 0.593, current mu = 0.501) allocation failure; GC in old space requested


<--- JS stacktrace --->

FATAL ERROR: Reached heap limit Allocation failed - JavaScript heap out of memory
 1: 0xb83f50 node::Abort() [ember]
 2: 0xa94834  [ember]
 3: 0xd647c0 v8::Utils::ReportOOMFailure(v8::internal::Isolate*, char const*, bool) [ember]
 4: 0xd64b67 v8::internal::V8::FatalProcessOutOfMemory(v8::internal::Isolate*, char const*, bool) [ember]
 5: 0xf42265  [ember]
 6: 0xf5474d v8::internal::Heap::CollectGarbage(v8::internal::AllocationSpace, [snip]
Aborted (core dumped)
error Command failed with exit code 134.

Y finalmente, al ejecutarlo con ./discourse_doctor se logró superar eso eventualmente (¿por qué, sin embargo? ¿más cosas en caché en ejecuciones posteriores que hicieron que usara menos memoria? :thinking:)

I, [2023-12-12T08:02:50.556442 #1]  INFO -- : > cd /var/www/discourse & su discourse -c 'bundle exec rake themes:update assets:precompile'
Node.js heap_size_limit (1010.0) is less than 1024MB. Setting --max-old-space-size=1024.
Node.js heap_size_limit (1010.0) is less than 2048MB. Disabling Webpack parallelization with JOBS=0 to conserve memory.
110:M 12 Dec 2023 08:07:50.026 * 100 changes in 300 seconds. Saving...
110:M 12 Dec 2023 08:07:50.030 * Background saving started by pid 3706
3706:C 12 Dec 2023 08:07:51.292 * DB saved on disk
3706:C 12 Dec 2023 08:07:51.294 * Fork CoW for RDB: current 1 MB, peak 1 MB, average 1 MB
110:M 12 Dec 2023 08:07:51.334 * Background saving terminated with success
Purging temp files
Bundling assets

Pero esto fue una fricción con la que no deberíamos haber tenido que lidiar. Esperemos que esto mejore en el futuro.

Para tu información:

# free -h
              total        used        free      shared  buff/cache   available
Mem:          1.9Gi       1.3Gi        87Mi       138Mi       593Mi       394Mi
Swap:         2.0Gi       337Mi       1.7Gi
1 me gusta
17

Definitivamente, por eso estamos recopilando información aquí.

Parece que ajustar nuestra variable de entorno NODE_OPTIONS es todo lo que se necesita, así que supongo que una dependencia de la aplicación o un cambio en V8 hizo que nuestro valor anterior allí ya no funcionara.

@david ¿cómo se ve esto?

1 me gusta
18

¡Me parece bien! Obviamente, las reconstrucciones de más de 30 minutos todavía no son ideales, así que espero que podamos mejorar las cosas en un futuro no muy lejano. Pero esta parece una buena solución para detener las pérdidas.

2 Me gusta
19

Cabe destacar que el aumento de la versión 16 de postgres en comparación con la versión 13 consume menos espacio y está mucho mejor optimizado. Esto puede reducir la cantidad total de memoria del servidor consumida.

20

He tenido un problema de reconstrucción similar hoy (dos contenedores) con una configuración de 2 GB + 2 GB de intercambio, para un sitio pequeño.

Ampliarlo a 2 GB + 4 GB de intercambio lo ha sacado adelante esta vez.

2 Me gusta
21

2 publicaciones se dividieron en un nuevo tema: La reconstrucción muestra “Entorno: desarrollo” durante la reconstrucción de ember-cli

22

Para que conste, en mi caso, añadir

a app.yml no ayudó. Lo que sí ayudó fue simplemente


sudo apt update
sudo apt upgrade
2 Me gusta