¡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
Asumiendo que estás en Linux, ¿qué muestra free -h? (Preferiblemente, inmediatamente después del reinicio y también poco antes del error.)
¿quizás swappiness está establecido en 0?
cat /proc/sys/vm/swappiness
¡Hola!
Estaba en 40, ahora lo he establecido en 60.
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.
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?
¡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.
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.
Aquí tienes una línea de comando sencilla y efectiva (aunque cron sería una mejor opción):
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.
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:
Y no está claro para mí exactamente cómo interactúan esas observaciones.
¡Sería bueno escuchar las respuestas!
Hmm, ¿qué hiciste exactamente? ¿Qué informa el siguiente comando para MEM USAGE / LIMIT y MEM %?
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.)
¡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.
Cuando ejecuto /var/log/monitor.log - uso tail -99 obtengo -bash: /var/log/monitor.log: Permiso denegado
(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.)
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
Creo que el 100% equivale a 1 núcleo. Porque el sistema funciona bien.
log.txt|adjunto (25.0 KB)
199 líneas del registro.
monitor.txt|adjunto (39.3 KB)
Aquí está el registro completo 
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.
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
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í?
