# Discourse no usa mucha RAM
**URL:** https://meta.discourse.org/t/discourse-not-using-much-ram/198805
**Category:** Self-hosting
**Tags:** server-resources
**Created:** [1 Agosto, 2021 10:14 UTC](https://meta.discourse.org/t/discourse-not-using-much-ram/198805 "2021-08-01T10:14:55Z")
**Posts on this page:** 20
**Page:** 1
### Author:  [@kianwalters05](https://meta.discourse.org/u/kianwalters05)
#### Post date: [1 Agosto, 2021 10:14 UTC](https://meta.discourse.org/t/discourse-not-using-much-ram/198805/1 "2021-08-01T10:14:55Z")
¡Hola!
Tengo Discourse en Docker y parece que nunca utiliza swap cuando la memoria RAM se agota, lo que provoca que se bloquee o muestre un error fatal: `fatal error: out of memory allocating heap arena map` si intento reconstruirlo. A menos que reinicie cada pocas horas, parece que no funciona.
¿Alguien sabe cómo solucionarlo?
Gracias,
Kian
---
### Author:  [@Ed\_S](https://meta.discourse.org/u/Ed_S)
#### Post date: [1 Agosto, 2021 11:55 UTC](https://meta.discourse.org/t/discourse-not-using-much-ram/198805/2 "2021-08-01T11:55:26Z")
Asumiendo que estás en Linux, ¿qué muestra `free -h`? (Preferiblemente, inmediatamente después del reinicio y también poco antes del error.)
---
### Author:  [@Benjamin\_D](https://meta.discourse.org/u/Benjamin_D)
#### Post date: [1 Agosto, 2021 12:08 UTC](https://meta.discourse.org/t/discourse-not-using-much-ram/198805/3 "2021-08-01T12:08:34Z")
¿quizás swappiness está establecido en 0?
`cat /proc/sys/vm/swappiness`
---
### Author:  [@kianwalters05](https://meta.discourse.org/u/kianwalters05)
#### Post date: [1 Agosto, 2021 20:10 UTC](https://meta.discourse.org/t/discourse-not-using-much-ram/198805/4 "2021-08-01T20:10:04Z")
¡Hola!
Estaba en 40, ahora lo he establecido en 60.
---
### Author:  [@kianwalters05](https://meta.discourse.org/u/kianwalters05)
#### Post date: [1 Agosto, 2021 20:15 UTC](https://meta.discourse.org/t/discourse-not-using-much-ram/198805/5 "2021-08-01T20:15:29Z")
El sistema siempre almacena en caché grandes bloques de RAM, y la memoria de intercambio nunca se utiliza, incluso cuando el uso de la RAM es alto.
---
### Author:  [@Ed\_S](https://meta.discourse.org/u/Ed_S)
#### Post date: [1 Agosto, 2021 20:39 UTC](https://meta.discourse.org/t/discourse-not-using-much-ram/198805/6 "2021-08-01T20:39:52Z")
Creo que las dos partes de la salida en las que hay que centrarse son los 5,5 GB de memoria disponible y los 0 B de swap utilizado. O tal vez los 9 GB de swap libre. La suma de 5,5 GB + 9 GB indica cuánto margen de maniobra tienes. La cantidad de memoria utilizada para buffers y caché es dinámica y nunca debería causar una escasez.
Dado que el tiempo hasta el fallo es de solo unas pocas horas, ejecutaría un `vmstat 5` y capturaría la salida de manera que se puedan ver los momentos finales. Anteriormente, solía usar una tarea programada (cron job) para ejecutar `vmstat 5 5` y guardar los resultados en un archivo de registro cada 10 minutos.
Es posible que, debido a un software que no funciona correctamente, se utilicen muy rápidamente todos los recursos disponibles. En ese caso, un registro de `ps uax` cada pocos minutos, para obtener varias instantáneas en los momentos cruciales, podría ser muy útil.
También es posible que estén influyendo otros límites. ¿Presumiblemente se trata de una instalación estándar en un sistema operativo estándar, sin que se ejecute nada más y sin configuración especial?
---
### Author:  [@kianwalters05](https://meta.discourse.org/u/kianwalters05)
#### Post date: [2 Agosto, 2021 12:27 UTC](https://meta.discourse.org/t/discourse-not-using-much-ram/198805/7 "2021-08-02T12:27:57Z")
¡Hola!
¿Cómo podría ejecutar vmstat 5 y guardar la salida en un registro cada 10 minutos? ¿Y cómo haría para que ps uax escriba en un registro cada pocos minutos?
Sí, es una instalación estándar de Ubuntu Server 18.04. Solo tengo cosas como Apache, Docker, etc.
---
### Author:  [@kianwalters05](https://meta.discourse.org/u/kianwalters05)
#### Post date: [2 Agosto, 2021 12:29 UTC](https://meta.discourse.org/t/discourse-not-using-much-ram/198805/8 "2021-08-02T12:29:07Z")
Recientemente me acordé de que también tengo Varnish Cache instalado, lo que explica la RAM que está en caché. Pero no entiendo por qué Discourse no usaría también el espacio de intercambio (swap). Hace unos días configuré su asignación con un comando de Docker para establecer su límite de swap, pero no tuvo ningún efecto.
---
### Author:  [@Ed\_S](https://meta.discourse.org/u/Ed_S)
#### Post date: [2 Agosto, 2021 13:13 UTC](https://meta.discourse.org/t/discourse-not-using-much-ram/198805/9 "2021-08-02T13:13:24Z")
> [@kianwalters05](#):
>
> ¿Cómo puedo hacer que vmstat 5 se escriba en un registro cada 10 minutos? Y, ¿cómo puedo hacer que ps uax se escriba en un registro cada pocos minutos?
Aquí tienes una línea de comando sencilla y efectiva (aunque cron sería una mejor opción):
```plaintext
sh -c 'rm -f /tmp/stop; while [! -e /tmp/stop]; do (date; uptime; free; ps faux; vmstat 5 5) >> /var/log/monitor.log; sleep 600; done' &
```
Se ejecutará indefinidamente: para detenerlo, usa `touch /tmp/stop`.
El registro aparecerá en `/var/log/monitor.log`. Usa `tail -99` para ver los últimos momentos o `less` para navegar por él. De alguna manera, necesitas encontrar las secciones del registro que muestren cómo se desarrolla el problema.
> [@kianwalters05](#):
>
> Pero no veo por qué Discourse no usaría también la memoria de intercambio (swap).
Siento que te estás haciendo la pregunta equivocada aquí. Es el kernel de Linux quien gestiona la memoria virtual, incluido el uso de búferes y la memoria de intercambio. Si `free` indica que la memoria de intercambio está configurada, es lo correcto y no tienes nada que hacer.
Tu verdadera pregunta debería ser: ¿por qué mi Discourse no funciona bien, por qué necesita reiniciarse y por qué estoy viendo el `fatal error`?
Te recomendaría mucho que cambies el título de este tema a:
¿Por qué “fatal error: out of memory allocating heap arena map”?
Además, me preocupa que parezca que tienes varias observaciones distintas:
- a veces Discourse se bloquea
- a veces veo “fatal error:… heap arena map” cuando reconstruyo
- a veces necesito reiniciar cada pocas horas
Y no está claro para mí exactamente cómo interactúan esas observaciones.
- ¿Qué te hace creer que Discourse se bloqueó: cuál es la observación?
- ¿Siempre ves “fatal error:” al reconstruir?
- ¿Por qué estás reconstruyendo?
- ¿Qué te lleva a reiniciar y te refieres a reiniciar el servidor?
¡Sería bueno escuchar las respuestas!
---
### Author:  [@Ed\_S](https://meta.discourse.org/u/Ed_S)
#### Post date: [2 Agosto, 2021 16:51 UTC](https://meta.discourse.org/t/discourse-not-using-much-ram/198805/10 "2021-08-02T16:51:02Z")
> [@kianwalters05](#):
>
> Hace unos días configuré su asignación con un comando de Docker para establecer el límite de intercambio, pero no surtió efecto.
Hmm, ¿qué hiciste exactamente? ¿Qué informa el siguiente comando para `MEM USAGE / LIMIT` y `MEM %`?
```plaintext
docker stats --no-stream --no-trunc
```
(En mi caso, el límite es un poco inferior a la memoria física de la máquina. Quizás esto signifique que es poco probable que nada que se ejecute dentro del contenedor provoque intercambio, y podrías ver que un proceso falle al asignar memoria incluso cuando hay poco o ningún intercambio en uso.)
---
### Author:  [@kianwalters05](https://meta.discourse.org/u/kianwalters05)
#### Post date: [3 Agosto, 2021 16:16 UTC](https://meta.discourse.org/t/discourse-not-using-much-ram/198805/11 "2021-08-03T16:16:23Z")
¡Hola!
Creo que Discourse se ha bloqueado porque cuando voy al dominio obtengo un error 502 Bad Gateway de Nginx. Sin embargo, el contenedor de Docker sigue activo.
Sí, excepto en ocasiones puntuales.
Lo reconstruí, ya que eso suele solucionar el error 502 Bad Gateway durante un tiempo.
También reinicié el servidor para ver si eso corrige el error; a menudo funciona, pero lo más probable es que no lo haga, y una reconstrucción lo soluciona por un tiempo.
También obtendré ese registro de errores pronto.
---
### Author:  [@kianwalters05](https://meta.discourse.org/u/kianwalters05)
#### Post date: [3 Agosto, 2021 16:24 UTC](https://meta.discourse.org/t/discourse-not-using-much-ram/198805/12 "2021-08-03T16:24:17Z")
---
### Author:  [@kianwalters05](https://meta.discourse.org/u/kianwalters05)
#### Post date: [3 Agosto, 2021 16:27 UTC](https://meta.discourse.org/t/discourse-not-using-much-ram/198805/13 "2021-08-03T16:27:37Z")
Cuando ejecuto `/var/log/monitor.log` - uso `tail -99` obtengo -bash: /var/log/monitor.log: Permiso denegado
---
### Author:  [@Ed\_S](https://meta.discourse.org/u/Ed_S)
#### Post date: [3 Agosto, 2021 17:02 UTC](https://meta.discourse.org/t/discourse-not-using-much-ram/198805/14 "2021-08-03T17:02:21Z")
(De tu captura de pantalla, veo que el contenedor llamado “app” tiene un límite de memoria de 7.8G y está usando solo el 3%, así que eso está bien. Edición: pero podría ser sospechoso que esté usando el 100% de la CPU.)
> [@kianwalters05](#):
>
> Cuando ejecuto `/var/log/monitor.log` - usa `tail -99`
Solo necesitamos ver el final de ese archivo de registro, así que
`tail -199 /var/log/monitor.log`
podría darnos lo que necesitamos. Pero quizás necesitemos ver más de él: ¿podrías comprimir el archivo de registro y adjuntarlo, o compartirlo de otra manera? ¿Qué tamaño tiene el archivo de registro?
`ls -l /var/log/monitor.log`
---
### Author:  [@kianwalters05](https://meta.discourse.org/u/kianwalters05)
#### Post date: [3 Agosto, 2021 17:04 UTC](https://meta.discourse.org/t/discourse-not-using-much-ram/198805/15 "2021-08-03T17:04:44Z")
Creo que el 100% equivale a 1 núcleo. Porque el sistema funciona bien.
---
### Author:  [@kianwalters05](https://meta.discourse.org/u/kianwalters05)
#### Post date: [3 Agosto, 2021 17:09 UTC](https://meta.discourse.org/t/discourse-not-using-much-ram/198805/16 "2021-08-03T17:09:56Z")
> [@Ed\_S](#):
>
> `tail -199 /var/log/monitor.log`
[log.txt|adjunto](https://meta.discourse.org/uploads/short-url/3ZbBxSOkJvBQVDncvCZYtCMlaLD.txt) (25.0 KB)
199 líneas del registro.
---
### Author:  [@kianwalters05](https://meta.discourse.org/u/kianwalters05)
#### Post date: [3 Agosto, 2021 17:13 UTC](https://meta.discourse.org/t/discourse-not-using-much-ram/198805/17 "2021-08-03T17:13:58Z")
[monitor.txt|adjunto](https://meta.discourse.org/uploads/short-url/cLKxxNl0c1zjZby7d81g9OOI93I.txt) (39.3 KB)
Aquí está el registro completo 🙂
---
### Author:  [@Ed\_S](https://meta.discourse.org/u/Ed_S)
#### Post date: [3 Agosto, 2021 17:34 UTC](https://meta.discourse.org/t/discourse-not-using-much-ram/198805/18 "2021-08-03T17:34:38Z")
Gracias. Todo eso parece correcto, pero solo es una instantánea única. Lo que debería ocurrir es que cada 10 minutos se agregue otra sección al registro. Espera a que aparezca el problema en tu Discourse, y luego comparte las últimas secciones.
Debo decir que no sé qué está pasando.
He notado que tus tres unicorns están consumiendo mucha CPU, y no sé por qué deberían hacerlo.
```plaintext
USUARIO PID %CPU %MEM VSZ RSS TTY STAT INICIO TIEMPO
COMANDO
x 434 51.9 2.8 443732 234144 ? Sl 18:26 0:11 \\_ unicorn master -E production -c config/unicorn.conf.rb
x 662 103 3.6 8877408 301148 ? Rl 18:26 0:08 | \\_ discourse sidekiq
x 686 99.7 3.6 8873312 301916 ? Rl 18:26 0:06 | \\_ unicorn worker[0] -E production -c config/unicorn.conf.rb
x 731 94.3 3.6 8873312 294368 ? Rl 18:26 0:05 | \\_ unicorn worker[1] -E production -c config/unicorn.conf.rb
x 744 77.2 3.3 8873312 276788 ? Rl 18:26 0:03 | \\_ unicorn worker[2] -E production -c config/unicorn.conf.rb
```
---
### Author:  [@supercobra](https://meta.discourse.org/u/supercobra)
#### Post date: [4 Agosto, 2021 21:56 UTC](https://meta.discourse.org/t/discourse-not-using-much-ram/198805/20 "2021-08-04T21:56:00Z")
Puedes ejecutar `top` y presionar `shift+m` para ordenar por uso de RAM y ver qué está consumiendo más memoria. ¿Podrías publicar el resultado aquí?
---
### Author:  [@kianwalters05](https://meta.discourse.org/u/kianwalters05)
#### Post date: [5 Agosto, 2021 11:10 UTC](https://meta.discourse.org/t/discourse-not-using-much-ram/198805/21 "2021-08-05T11:10:39Z")
[Página siguiente](https://meta.discourse.org/t/discourse-not-using-much-ram/198805.md?page=2)