¿Hay alguna guía (o temas aquí en el foro) que ofrezca consejos sobre el ajuste de un servidor que aloja sitios de Discourse para mejorar el rendimiento?
Ejecuté el comando ./Discourse-set y configuró un cuarto de la memoria RAM (a 4096 MB) y agregó 8 workers de unicornio, pero ¿hay algo más que podamos hacer o ajustar en esto?
El servidor tiene 64 GB de RAM ECC y dos SSDs de 512 GB NVMe (en una matriz RAID). Al observar el comando top, solo se están utilizando alrededor de 5 GB de memoria, con 57392484 avail Mem. También ejecuta otros sitios que no usan Docker, pero no consumen muchos recursos y MySQL ya está ajustado para una base de datos grande de 2 GB. Las cargas promedio generalmente están por debajo de 1.0 (normalmente entre 0.50 y 1.0, con ocasionales picos por encima). No se han reportado problemas, pero espero aprovechar al máximo el servidor.
Me pregunto si debo comenzar duplicando db_shared_buffers… y qué hay de #db_work_mem: "40MB", que actualmente está comentado.
Hay (o hubo) algunos temas sobre optimización. La mayoría de los exitosos, creo (excepto este), proporcionan detalles precisos sobre los recursos disponibles, db_shared_buffers y otras configuraciones, y cuáles son los problemas, quizás con la salida de htop u otras herramientas. ¿Qué tamaño tiene tu base de datos? ¿Qué problema tienes? (Quizás quieras iniciar un nuevo tema)
¡Gracias! Todavía no hay problemas. Solo noto un alto uso de memoria, pero no es un foro concurrido. Estoy acostumbrado a pensar de forma proactiva y a comprobar qué recursos se estaban utilizando más. Esto es solo en un VPS de 3 GB con 6 núcleos a 3,5 GHz. No es lento, es muy rápido, solo que puedo ver que el uso de memoria se convertirá en un problema futuro y tengo curiosidad sobre qué puedo ajustar.
Leeré más sobre la optimización general de aplicaciones Ruby on Rails. Gracias de nuevo.
Dependiendo de qué medida de “uso” quieras decir, eso podría ser normal. Pero con 3 GB, probablemente no haya mucho que ajustar, ya que si ejecutaste ./discourse-setup, sus suposiciones probablemente sean “lo suficientemente buenas”.
free -h
total used free shared buff/cache available
Mem: 2.9Gi 1.8Gi 167Mi 100Mi 1.0Gi 895Mi
Swap: 1.0Gi 587Mi 436Mi
Disponible es ~ 900M. Todavía no es un problema. Pero un problema no me trajo aquí. Me gustaría saber qué hacer si/cuando la memoria disponible se convierta en un problema en el futuro. Además de añadir más memoria, por supuesto.
En este nivel, lo único que realmente se puede hacer será añadir más RAM. Si tienes 8 o 16 GB, entonces hay algunas cosas que hacer. En todo caso, podrías querer añadir otro GB de swap, pero probablemente estarás bien.
Si ejecutaras ./discourse-setup, habría creado un archivo de swap de 2 GB. Podrías tener problemas cuando hagas una reconstrucción.
Bien, pude casi duplicar el uso de memoria disponible cambiando la configuración predeterminada de instalación de: UNICORN_WORKERS: 8
a UNICORN_WORKERS: 4
Luego: sudo ./launcher rebuild app
Ahora estoy configurando la monitorización de PostgreSQL y veré qué está pasando allí.
Siempre hay un momento en que algún recurso se convierte en un cuello de botella. Pero su servidor actualmente parece excesivamente sobredimensionado para mí.
Usará más memoria cuando tenga más procesos de Unicorn.
Necesitará más procesos de Unicorn cuando tenga más tráfico en su sitio.
Veo que todos los procesos de Unicorn usan 0.0% de CPU y solo worker[0] parece estar haciendo algo.
Redujo la memoria ejecutando menos Unicorns. Eso es bueno, porque de todos modos no parecía usarlos. Pero la memoria disponible es en realidad algo malo. Está optimizando para la variable incorrecta.
La memoria no utilizada no le aporta nada. Significa que está pagando por algo que de todos modos no está utilizando. Si tiene 2 GB disponibles todo el tiempo*, podría reducir el tamaño de su servidor y ahorrar algo de dinero.
*) Reconstruir Discourse consumirá más memoria, por lo que necesita verificar cuánta memoria está disponible durante la reconstrucción. En la práctica, no baje de los 2 GB totales y/o asegúrese de tener suficiente intercambio, como ya dijo Pfaffman.
No es correcto. La memoria “libre” que no hace nada es mala. Pero la memoria “disponible” es memoria que está siendo utilizada por el sistema y que puede liberarse fácilmente, lo cual es algo bueno.
O oficialmente:
Memoria disponible: Estimación de cuánta memoria está disponible para iniciar nuevas aplicaciones, sin paginación.
Fuente: man free
Según la captura de pantalla a continuación, la memoria libre apenas ha cambiado. Por lo tanto, casi toda la memoria del sistema se está utilizando. Sin embargo, el sistema paginará menos ahora porque hay más memoria disponible que se puede liberar cuando sea necesario.
Supongo que mala aquí significa que cuesta, pero no da nada. Esa es una forma de pensar bastante común, porque cuando se necesitan más recursos, también será más caro, y la RAM es una parte costosa en esa ecuación.
Y si no tienes demasiado dinero para malgastar, es un poco estúpido pagar demasiado (expresión publicitaria finlandesa, sin ofender )
)