Entonces, ¿todas las afirmaciones de que el UNICORN WORKER debería ser 2*vCPU son incorrectas?
Mi servidor es Intel Xeon E5-2686 v4 @ 2.30GHz—24vCPU+32GB RAM
¿Cuántos UNICORN WORKER necesito configurar?
¿8? ¿o 48?
Mi sitio tiene más de 7k usuarios y alrededor de 1k usuarios activos diarios. Los usuarios envían entre 3k y 7k publicaciones por día. Nuestra comunidad tiene entre 120k y 200k visitas a páginas por día, incluidos rastreadores y usuarios anónimos.
Eso depende de muchos factores. Como el tamaño de tu base de datos en comparación con tu RAM, la proporción de tráfico de usuarios conectados frente a anónimos, si tienes plugins que mantienen tu cola de Sidekiq más ocupada, si estás ejecutando YJIT, etc.
Lo que es simple es mirar los datos de MiniProfiler durante tu hora pico y navegar por el foro para ver si el rendimiento es peor e identificar el cuello de botella.
Dado que esta CPU es antigua, comenzaría con más trabajadores de Unicorn de lo habitual, ya que cada solicitud tardará más de lo normal. Pero si estás ejecutando PostgreSQL y Redis en el mismo servidor, no puedes privarlos de recursos ejecutando demasiados trabajadores.
Intenta ejecutar 16 trabajadores para empezar y evalúa cómo está funcionando el sitio.
¿Existe una descripción sencilla y fácil de entender de lo que hacen los trabajadores de Unicorn? Tengo la impresión de que cada solicitud de página de usuario tiene que ir a un trabajador de Unicorn para ser procesada. Si no tienes suficientes, el usuario tiene que esperar. Si tienes demasiados… bueno, ¿quizás te cuesta un poco de RAM?
Son los servidores web de aplicaciones.
1 me gusta
No es hora punta ahora, pero creo que hay un problema con el tiempo de carga.
¡La imagen muestra un gráfico de monitoreo de rendimiento en una aplicación de renderizado, con varios tiempos para diferentes tareas incluyendo solicitud GET, operaciones de renderizado y consultas SQL, indicando un tiempo total de consulta de 1500.5 milisegundos y una duración de respuesta de 62 milisegundos. (由 AI 生成标题)|690x272
Parece que tu CPU de 10 años está mostrando su edad. Aumentar los trabajadores de Unicorn te permitirá atender a más usuarios simultáneamente, pero no hará que una solicitud individual sea más rápida.
¿Puedes intentar habilitar YJIT?
3 Me gusta
Con tu hardware, esperaría obtener una lista de inicio de sesión/tiempo más reciente promedio de alrededor de 150 ms en la aplicación, 80 ms en SQL.
Empezaría con 12 trabajadores y vería cómo se comporta con eso. Lo mejor que puedes hacer es rastrear métricas; si quieres saber si debes agregar más trabajadores, comprueba si las solicitudes se están poniendo en cola esperando a los trabajadores de la aplicación.
¿Estás rastreando las métricas que Discourse exporta a través del exportador de Prometheus? Estas te darán una buena visión del rendimiento general de la instancia.
¿Cómo son los números de rendimiento para los usuarios anónimos y regulares (no administradores)?
5 Me gusta
Hay muchos mega temas en nuestro Discourse, y el más grande ya está en la duodécima sección.
Vistas de respuesta
1 me gusta
(/deja de reír, inicia sesión en el proveedor de alojamiento … )
vaya, ¿no es esto lo predeterminado ya?
edición: ah, por supuesto, es posible que hayas compilado con una app.yml antigua y no la hayas actualizado desde entonces.
1 me gusta
Está en nuestro hosting, pero es un poco difícil hacerlo predeterminado, ya que la gente puede estar ejecutándose en escenarios con restricciones de RAM…
Dicho esto, nuestra compilación de JS utiliza mucha más RAM que el propio Discourse, por lo que se podría decir que cualquiera que pueda compilar los activos de JS tiene mucha RAM de sobra 
1 me gusta
En estas imágenes, ¿cuántos trabajadores tienes configurados?
Yo diría que deberías
- Aumentar un poco los trabajadores, ya que se produce una pequeña cola
- Habilitar YJIT, ya que tu tiempo web es bastante lento
Ahora solo hay 8 trabajadores y YJIT ya está habilitado.
¿Cuántos trabajadores debería aumentar?
Por cierto, esto es lo que Falco estaba mirando para hacer esa recomendación:
Aumentaría de 8 a 12. Te da algo de margen y debería despejar esas colas.
Ese gran pico, por cierto, es indicativo de las otras solicitudes esperando… algo, probablemente un bloqueo común. Quizás una publicación de mega tema.
Si también puedes obtener métricas de uso de postgres, sería útil.
los mega temas son un punto débil, ver Improving Instance Performance (Megatopics, Database Size and Extreme Load)
Considere dividir estos o usar el chat en su lugar (veo que su sala más grande con 8.9k respuestas es explícitamente una sala de chat).
La cultura de debate de nuestra comunidad son los megatopics, que se formaron incluso antes de que empezáramos a usar Discourse, y al chat le faltan las funciones de spoilers difuminados y detalles ocultos.
1 me gusta
Cómo hacerlo
Usamos GitHub - prometheus-community/postgres_exporter: A PostgreSQL metric exporter for Prometheus, aunque no estoy seguro de si hay alguna guía sobre meta en cuanto a su configuración.
Pero, dado que parece que ya tienes prometheus configurado, parece que sabes lo que haces.
ahora la RAM del servidor es 16/32 GB, UNICORN_WORKERS: 12, db_shared_buffers: “4096MB”
Dado que todavía hay RAM disponible y pocas solicitudes web en cola, aumenté UNICORN_WORKERS a 24. Por la tarde de hoy, el servidor se apagó repentinamente y, después de reiniciarlo, los usuarios llegaron inmediatamente. Esto provocó un número muy bajo de Solicitudes Web Activas y un gran número de solicitudes en cola. Hace unos días, observamos que 24 UNICORN_WORKERS podían manejar más de 150 Solicitudes Web Activas, pero solo 30 Solicitudes Web Activas esta tarde. Esto se debe a que acabamos de cambiar el dominio y hay muchas publicaciones que sidekiq está volviendo a hornear. Esto ha causado mucha presión en el servidor. ¿Qué debemos hacer?
