¿Podría esto indicar que UNICORN_WORKERS está configurado demasiado alto/bajo?
El servidor tiene 64 GB de RAM (generalmente muestra alrededor de 40 GB libres) y 6 núcleos, hay 4 instancias de Discourse en el servidor, cada una configurada en UNICORN_WORKERS: 8
¿Alguna idea o consejo sobre qué lo está causando o qué intentar? (Uno de los foros está en modo de solo lectura y no recibe mucho tráfico, ¿debería configurarse para tener menos trabajadores?)
Gracias por las respuestas a todos. No estoy seguro de dónde lo leí ahora, pero siempre pensé que debíamos configurar 2 trabajadores por núcleo. He reducido los trabajadores ahora por foro, asignando más a los foros más activos y menos a los que no lo están tanto. Supervisaré las cosas durante la próxima semana y volveré a informar si no ha ayudado.
En su caso, sin embargo, no está asignando dos trabajadores por núcleo. Tiene seis núcleos, lo que significaría doce trabajadores, pero tiene cuatro instancias, cada una usando ocho trabajadores, para un total de 32.
Sí… He ajustado para que el número total de trabajadores no sea mayor que el doble del número de núcleos, aunque todavía me pregunto: ¿cuál es el consejo correcto/estándar, lo que dijiste o lo que estaba en la publicación de Nate, donde cita a Jeff diciendo 1 trabajador por núcleo?
Según mis propios experimentos, 1 trabajador por núcleo resulta en tiempos de espera (pero reduce la carga del servidor), más trabajadores resultan en un mejor rendimiento pero una mayor carga (que en mi servidor todavía está dentro de un rango aceptable).
Echa un vistazo a discourse-setup, que se encarga de la escalabilidad para nuevas instalaciones hoy en día:
# UNICORN_WORKERS: 2 * GB para 2GB o menos, o 2 * CPU, máximo 8
if [ "$avail_gb" -le "2" ]
then
unicorn_workers=$(( 2 * $avail_gb ))
else
unicorn_workers=$(( 2 * $avail_cores ))
fi
unicorn_workers=$(( unicorn_workers < 8 ? unicorn_workers : 8 ))
Esa segunda declaración, que utiliza el doble del número de núcleos disponibles, es la predeterminada en sistemas con más de 2 GB de RAM. Parece que tu problema se debe más a un tira y afloja entre tus instancias (recursos del host) que a un problema de discourse.
Estoy viendo lo mismo después de mi última actualización, que fue un día después del OP, así que no creo que esto tenga nada que ver con el número de trabajadores de unicornio. El proceso unicorn.conf.r* es sospechoso, porque la publicación original de este tema es el único resultado para ese término en toda la web. Creo que unicorn.conf.rb sería más normal.
Acabo de actualizar a la última versión de Discourse y ya no veo unicorn.conf.r* (ahora cualquier cosa alrededor del 80% de la marca de CPU es solo ruby, aunque parece menos frecuente). Las cargas son aproximadamente las mismas (aunque menores que después de hacer esos ajustes de trabajadores).
¿Te has actualizado a la última versión? ¿Qué tipo de hardware tienes y qué tan ocupado está tu foro?
Sí, estoy en la versión 3.4.0.beta4-dev. Eso es lo que inició el alto uso de CPU. Nada más cambió.
8 GB de RAM, 2 vCPUs, SSD de 160 GB con mucho espacio.
Publiqué el uso de CPU anterior para mi sitio de producción, que tiene alrededor de 30 usuarios en línea a la vez. Pero tengo un sitio de prueba con el mismo problema y no hay absolutamente nada de tráfico ni plugins allí. Uso de CPU antes y después de actualizar (los picos son copias de seguridad diarias):
No estoy seguro de si nuestras situaciones están relacionadas, Mark. Creo que en mi caso, lo que dijo Stephen jugó un papel importante:
Recientemente trasladé otras dos instancias al mismo servidor y había olvidado que los workers de unicorn estaban configurados en 8 porque anteriormente estábamos en un servidor con más núcleos (pero tenía sus propios problemas, por lo que volvimos a un Xeon que tenía menos núcleos pero funcionaba mejor en general).
Así que lo que descubrí fue que reducir los workers de unicorn en este servidor redujo la carga, pero comenzó a darnos tiempos de espera, aumentarlos erradicó los tiempos de espera pero resultó en una carga mayor, aunque todavía dentro de un rango aceptable. Creo que podría aumentar los workers y aún podríamos manejar la carga aumentada, pero lo que tenemos ahora es bueno por ahora.
Habiendo dicho eso, había trasladado las instancias al mismo servidor y estaba funcionando dentro de lo que hubiera esperado (la carga aumentó pero no mucho) y sentí que una actualización resultó en cargas más altas… sin embargo, no puedo estar seguro de eso, y debemos tener en cuenta que de vez en cuando, a medida que Discourse obtiene más funciones, puede requerir hardware más potente o resultar en que a veces se sienta “más lento” (tuve algunas instancias de Discourse en versiones antiguas y se sentían notablemente más ágiles, aunque por supuesto no tenían todas las funciones de las versiones más nuevas).
Habiendo dicho eso también, creo que las cargas en realidad han disminuido un poco desde la última actualización de Discourse (con PG 15).
No estoy seguro de qué sugerirte, Mark, ¿quizás jugar con los workers y algunas de las otras configuraciones también? ¿Como db_shared_buffers y db_work_mem? ¿Quizás iniciar un hilo dedicado del tipo “Uso alto de CPU después de la actualización - ¿necesita mi instancia ajustes de rendimiento?” O algo así
Me actualicé esta noche e inmediatamente noté una diferencia en el uso de la CPU en mi sitio. Aquí hay un gráfico de antes, durante y después de la actualización. Esto representa una duración de una hora.
Aquí están los resultados 15 horas después de la actualización. El porcentaje de uso de la CPU ha aumentado drásticamente en 3 veces. El factor de carga ha aumentado en 4 veces.
Así que parece que mi problema no fueron los unicorn workers después de todo. Después de la actualización de @sam, siguiendo el hilo de @LotusJeff, las cargas del servidor han vuelto a ser las que eran (menos de la mitad de lo que habían aumentado)…
Probablemente no me habría dado cuenta si no hubiera estado vigilando el servidor después de haber trasladado recientemente los otros dos foros. Me pregunto a cuántas personas afectó sin que se dieran cuenta.
¿Tiene el equipo de Discourse medidas implementadas para alertarlos de problemas como este? ¿Quizás un programa de voluntarios que los administradores puedan configurar para temas específicos, por ejemplo, “Enviar cargas del servidor a Discourse XX horas/días/semanas antes/después de una actualización”? O mejor aún, rastrear esto localmente y luego alertar a los administradores cuando se noten aumentos en la carga del servidor después de las actualizaciones, lo que luego podemos publicar aquí si es necesario.
Probablemente no habría notado el impacto, pero estoy monitoreando el servidor de cerca porque migramos a Discourse hace aproximadamente 2 semanas. Estoy inmerso en varias validaciones posteriores a la migración (ejecución de copias de seguridad, etc.). Después de un par de meses, nunca habría notado el impacto.
Esperaría que Discourse tuviera una prueba de carga diaria. En mi vida pasada, tuve un servidor que se reconstruía diariamente con código confirmado. Tenía usuarios simulados usando el servidor todo el día. Medimos métricas clave de rendimiento desde la perspectiva del usuario y del servidor. Nos permitió detectar de forma proactiva fugas de memoria, código ineficiente y cambios inesperados en la experiencia del usuario.
Todavía tengo que felicitar a Sam y al equipo. Viniendo del mundo de phpBB, donde algo como esto llevaría décadas resolver y remediar, encontré la respuesta rápida fantástica. (Incluso si significaba quedarme despierto hasta las 2 a.m. hora CT en comparación con la hora de Sydney).
