Entiendo. ¿No sería posible optimizar el proceso de arranque/compilación para que tarde más (CPU/serializar) pero dentro de recursos limitados (es decir, RAM)?
1 me gusta
Creo que sería una gran idea. Y una de las razones es esta: si uno no puede reconstruir en un servidor pequeño, entonces no puede instalar en un servidor pequeño. Y si uno instala en un servidor de tamaño mediano, no obtendrá el archivo de paginación creado que se necesitará en el servidor pequeño. (Idealmente, el script de instalación crearía el archivo de paginación de todos modos, y también establecería los dos parámetros del kernel que deberían establecerse).
Esta también es una gran idea. De la misma manera que, idealmente, un proceso de ingeniería de software monitoriza los tiempos de compilación, porque de lo contrario los tiempos de compilación se alargan cada vez más, para Discourse el proceso idealmente probaría y monitorizaría la instalabilidad en instancias pequeñas. Hazlo un objetivo.
1 me gusta
He experimentado con la creación de imágenes bootstrapped que migran y precompilan activos al iniciarse (con configuraciones de ENV para omitir esas tareas). Esto funciona en su mayor parte (no tanto para sitios enormes y para cosas que dependen de que el inicio ocurra en un cierto período de tiempo).
Sin embargo, dependen de que existan redis y postgres.
Con una instalación de 2 contenedores mayormente estándar, podría ser posible que funcione en su mayor parte.
Ooooooooooooooooooooooh, pero la precompilación de activos, supongo, es el paso que está causando los problemas. . .
Estoy leyendo sobre esta actualización de Ember 5 que está en proceso. ¿Qué impacto tendría en los recursos de compilación?
Creo que la documentación necesita una actualización, discourse/docs/INSTALL-cloud.md at main · discourse/discourse · GitHub
- La configuración predeterminada de 1 GB de RAM funciona bien para comunidades pequeñas de Discourse.
1 GB ya no es una opción. El requisito mínimo es 2 GB para compilar Discourse.
1 me gusta
Actualicé recientemente una gran cantidad de sitios con 1 GB de RAM. Sin embargo, aumenté su swap a 3 o 4 GB.
Ciertamente no lo recomiendo, pero para algunas personas es una gran barrera de costos y se las arreglan. Pero tal vez “funciona bien” sea una exageración.
3 Me gusta
Sí, quizás especifica eso, 1 GB de RAM + 4 GB de intercambio. Falló con 2 GB de intercambio.
¿Tienes algún plugin? ¿Muchos temas?
9 complementos y solo 1 tema. Nuevamente, todo esto funcionó muy bien hasta la versión 3.1.x con 1 GB de RAM y 2 GB de intercambio (era un poco lento, tal vez 20 minutos para reconstruir, pero siempre funcionó).
Intentar actualizar a la versión 3.2.0 falló constantemente (ver arriba).
Sí. Definitivamente no hay complementos con 1 GB de RAM. Parece algo que añadir a la documentación de instalación.
Me interesaría saber si funcionó sin los complementos.
Como una abreviatura extrema, puedo ver por qué dirías esto, pero ¿no estás de acuerdo en que el sí/no para ejecutar Discourse es RAM + swap? 1+3 es tan bueno como 2+2 desde el punto de vista de sí/no.
Es solo el rendimiento (capacidad de respuesta) lo que importa cuánta RAM tienes.
RAM + swap es lo correcto para verificar y probar. Memoria = RAM + swap.
Por cierto, si algo no funciona sin una evidencia obvia de por qué, y especialmente si sospechas de falta de memoria, vale la pena verificar el asesino de falta de memoria, también conocido como el OOM-killer. Recomiendo
dmesg|egrep -i "memory|oom|kill"
Editar: por conveniencia, lo agregaré a mi lista de diagnósticos instantáneos estándar:
cat /etc/lsb-release
uptime
df -h /
free
vmstat 5 5
dmesg|egrep -i "memory|oom|kill"
ps auxrc
5 Me gusta
Encontré el mismo problema, pero no durante una actualización, sino al realizar una instalación nueva de la versión 3.2.0.
Estoy usando AWS EC2, al igual que @RBoy.
Estoy buscando una solución para instalar la versión 3.1.5 en lugar de la 3.2.0, ya que el foro anterior no proporcionó ninguna ayuda.
ACTUALIZACIÓN:
lo siento, encontré esto:
1 me gusta
Me interesaría mucho saber si pudiste hacer una instalación limpia de la versión 3.1.5 utilizando el método de etiqueta mencionado en tu enlace. Por favor, responde si lo pruebas.
En cuanto a la instalación de la versión 3.2.0 en un sistema de 1 GB, podrías intentar esto: configura tu tamaño de SWAP a 8 GB y mira si funciona. Probablemente irá LENTÍSIMO, pero podría funcionar.
Gracias por tu valiosa orientación.
Recientemente completé una instalación limpia de la versión Docker de Discourse 3.15 y quería compartir lo sencillo que fue el proceso, especialmente para aquellos que utilizan el nivel gratuito de AWS EC2, como yo.
Aquí tienes una guía concisa basada en mi experiencia:
-
Navega hasta tu archivo de configuración de Discourse ubicado en
/var/discourse/containers/app.yml. -
En la sección
params, actualiza el parámetroversionpara que coincida con la versión deseada de Discourse. Por ejemplo:params: # ... ## Especifica la revisión de Git para este contenedor (predeterminado: tests-passed) version: v3.1.5 # Usa el nombre de etiqueta específico aquí -
Guarda tus cambios y sal del editor. Luego, ejecuta el siguiente comando para reconstruir tu aplicación de Discourse:
/var/discourse/launcher rebuild app
El proceso funcionó sin problemas para mí, lo que demuestra que mantener una configuración de Discourse de bajo costo o incluso sin presupuesto es totalmente factible.
Espero que esta guía ayude a otros que buscan administrar sus instalaciones de Discourse de manera eficiente y rentable.
2 Me gusta