Are there any guides (or Topics here on the forum) that provide tips on tuning a server that hosts Discourse sites for performance?
I ran the ./Discourse-set and it set a quarter of the ram (to 4096mb) and added 8 unicorns workers - but is there anything else we can do, or tweak these?
The server has 64GB ECC Ram and two 512GB NVMe SSDs (in a raid array). Looking at top, only around 5GB of memory us being used, with 57392484 avail Mem. It does run other non-Docker sites, but they don’t use up much of the resources and MySQL is already tuned for a large 2GB db. Load averages are generally below 1.0 (usually around 0.50 up to 1.0 with occasionally going over). No problems have been reported, but I am hoping to utilise as much of the server as possible.
I’m wondering whether to start by doubling db_shared_buffers… and what about #db_work_mem: "40MB" which is currently commented out.
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 )
)