Parece que 2+2 ya no es suficiente… Estoy administrando una instancia de Discourse bastante modesta (sin plugins grandes/elegantes, etc.) que, a partir de hoy, no arranca porque Ember está consumiendo toda la RAM que puede encontrar, y toda la memoria de intercambio (swap), y haciendo que la máquina se vuelva irresponsable. Agregar otros 2 GB de memoria de intercambio permitió que el arranque se completara, con un uso máximo de memoria de intercambio de alrededor de 2.5 GB.
Vaya, esto está en la lista de @david para investigar.
5 Me gusta
@david ha estado investigando, confirmamos que, tal como está, 2 GB son suficientes para las reconstrucciones de Docker, pero no son suficientes para que funcione el actualizador web.
Una idea que he planteado es simplemente detener todos los procesos de Ruby durante el actualizador web para ahorrar entre 300 y 500 MB adicionales, lo que dejaría suficiente para la precompilación de activos.
Un enfoque a largo plazo que probablemente tendremos que adoptar para los autoalojadores es enviar contenedores preiniciados, lo que es una caja de Pandora, ya que ¿cómo podría un actualizador web lograr eso? No queremos montar sockets de Docker…
Es un verdadero dilema.
2 Me gusta
Bueno, no lo fue para mí.
¿Se compara esto entre una instalación básica pura y situaciones del mundo real?
De hecho, no es perfectamente consistente. Incluso con todo lo demás cerrado, todavía puede fallar.
Desafortunadamente, estamos librando una batalla perdida contra las herramientas modernas de compilación de JS. Todo está diseñado para ejecutarse en 8 GB o más de RAM en máquinas de desarrollador modernas, no en VPS de 1 GB 
Tenemos algunas soluciones en mente. Por ejemplo: proporcionar activos precompilados que se puedan descargar automáticamente. El gran desafío que tenemos son los complementos, porque varían en cada sitio y, en este momento, están estrechamente integrados en la compilación principal.
Pero por ahora, una reconstrucción completa de la CLI debería tener una tasa de éxito mayor que una actualización de la interfaz de usuario web.
8 Me gusta
Al igual que Jagster, 2 GB de RAM + 2 GB de intercambio no son suficientes para mi reconstrucción de Docker impulsada por CLI. Al revisar más a fondo, los únicos complementos en esta instalación son docker_manager y discourse-prometheus, ninguno de los cuales, esperaría, pondría una carga inesperada en ember.
Si las especificaciones mínimas tienen que cambiar, sería terrible, pero sería mucho mejor que la situación actual, donde las máquinas inesperadamente se ralentizan hasta morir en cada actualización.
7 Me gusta
Si ese es el caso, creo que aún sería mejor aumentar un poco las especificaciones recomendadas. Personalmente, no me importa añadir 2 (o incluso 4) GB más de swap si hace que las reconstrucciones sean más fiables, al menos mientras las operaciones diarias sigan estando bien con 2-4 GB de RAM (para comunidades pequeñas y medianas).
2 Me gusta
De hecho, la instalación inicial falló en mi instalación reciente en una instancia de 4c 4g. Ed sugirió crear un archivo de intercambio. Encontré el tema para crear un intercambio y creé un intercambio de 4g. Ahora todo funciona como se esperaba en la actualización/mejora web o CLI.
En mi opinión, es posible que debamos aceptar que Discourse requiere más RAM de la que solía necesitar.
3 Me gusta
¿No tendría sentido zram?
Hemos implementado este commit que esperamos mejore la situación. ¡Por favor, háganos saber cómo le va! (llegará a tests-passed en los próximos ~30 minutos).
Al probar con un contenedor docker con memoria limitada localmente, ahora puedo obtener una compilación exitosa con -m 1600m. Antes de este cambio, el mínimo que podía lograr era -m 3000m.
12 Me gusta
Hice una reconstrucción de prueba (instalación limpia), que se completó sin problemas. Ahora esa máquina tiene 4 GiB de RAM (Hetzner CAX11) y un archivo de paginación del mismo tamaño, por lo que ciertamente tiene menos restricciones que la configuración de 2+2 GB mencionada anteriormente. Sin embargo, el uso del intercambio fue mínimo durante toda la compilación y el uso máximo de RAM que vi fue de ~3.1 GB. Y la mayor parte del tiempo, se mantuvo alrededor de ~2 GB, por lo que no parece tan malo (el tiempo de compilación fue más o menos el mismo, es decir, unos 8 minutos).
4 Me gusta
Me gustaría mucho realizar algunos experimentos controlados, con instalaciones y reconstrucciones limpias, en una variedad de configuraciones, y en particular me gustaría ver la diferencia (si la hay) de ejecutar con sobreasignación de memoria virtual (vm overcommit), pero me temo que me ha faltado tiempo.
(Sin sobreasignación, un proceso grande que se bifurca tendrá un aumento instantáneo en la huella de memoria que podría ser fatal, y no aparecerá en un monitor encuestado. Incluso con sobreasignación, el aumento de memoria podría ser lo suficientemente rápido como para no aparecer en una encuesta, ya sea htop o vmstat o algo más).
No creo haber visto nunca a nadie ofrecer voluntariamente si está ejecutando con o sin sobreasignación, aunque en mi opinión es un aspecto importante de la configuración del host.
1 me gusta
Apuesto a que la mayoría de la gente no lo hace.
Lo configuro automáticamente en mis instalaciones. Aún así, recibo esa advertencia al respecto.
El overcommit es irrelevante aquí, porque el problema no son los procesos que son eliminados prematuramente por OOM (Out Of Memory), sino simplemente intentar meter diez libras de memoria asignada en un saco de cinco libras.
No es prácticamente posible ejecutar una reconstrucción de Discourse con overcommit_memory=2, porque ember (entre otras cosas, sin duda) preasigna masas de memoria virtual (si no recuerdo mal, unos 80 GB es lo que vi), por lo que eso siempre incumplirá cualquier configuración razonable de overcommit_ratio. Establecer overcommit_memory=1 tampoco ayudará, porque, de nuevo, el problema no es un VMM (Virtual Memory Manager) demasiado celoso que elimina procesos, sino una gestión de memoria terriblemente deficiente por parte del compilador de ember.
1 me gusta
¡No estoy seguro de estar totalmente de acuerdo con tu análisis! Según entiendo, la sobreasignación (overcommit) permite a los procesos asignar memoria que no utilizan. No se trata solo del comportamiento del OOM-killer. Pero como digo, me gustaría realizar algunos experimentos controlados, esa es una mejor manera de ver qué marca la diferencia y qué no.
Tengo 4 GB de RAM y muchos plugins (sin archivo de intercambio del que esté consciente). ¿Cuántos plugins tienes tú y crees que unas 4 GB de RAM en blanco son suficientes?
Parcialmente correcto, pero aun así, es irrelevante, porque el problema que se discute en este tema son procesos que asignan memoria que sí tocan, y tocan más de la que el sistema tiene disponible, lo que causa interrupciones visibles para el cliente.
¿Puedes confirmar que después de los cambios de @david los requisitos de memoria han disminuido? Deberíamos estar en un estado razonable ahora.
El próximo gran salto será la precompilación y los activos precompilados distribuidos, es un cambio bastante grande para llegar allí, pero borrará un gran montón de trabajo de Internet una vez hecho.
2 Me gusta
Con el debido respeto, no estoy seguro de eso. He visto archivos de registro que muestran fallos en la bifurcación. Estamos diciendo en este hilo que son “requisitos de memoria”, pero eso incluye, en mi opinión, las tácticas del kernel para la memoria virtual. Claramente, un experimento o tres mostrará si tengo razón o no sobre el overcommit.
Esa fue una compilación limpia sin ningún plugin. Puedo probar con otra con algunos plugins habilitados y tal vez deshabilitar temporalmente el swap para confirmar que la compilación se realiza (aunque probablemente me tome algunos días hasta que tenga tiempo).
2 Me gusta