este mensaje empezó a aparecer casi constantemente desde la última vez que actualicé discourse hace un par de días.
No habría abierto un tema aquí si no fuera porque… no es cierto.
El mensaje aparece pero puedes navegar por el foro como si hubieras iniciado sesión, nada se muestra realmente como si no lo hubieras hecho.
Al verificar los recursos utilizados/disponibles en el host, no se muestra que la máquina esté sobrecargada ni nada parecido.
¿Alguien puede ayudarme a entender cómo se activa este mensaje para que pueda empezar a investigar qué podría estar causando esta advertencia cuando en realidad no es el caso?
Ese mensaje es significativo, el hecho de que tu sistema tenga recursos libres es más indicativo de una configuración errónea que de una identificación errónea.
¿Cuántos unicorn_workers tienes?
Suponiendo que no hay nada más en el host, ¿has asignado 16 (dos por núcleo)?
Si estás usando Postgres local, ¿cuáles son tus db_shared_buffers?
Dejé la configuración predeterminada del ./launcher en la configuración inicial y fueron 8 workers.
Lo mismo para db_shared_buffers: 4096MB
Sin embargo, debido a algunas pruebas, la razón por la que puedes leer aquí, los workers se redujeron a 4. No tuvo ningún efecto, así que al menos puedo restaurarlos a 8.
La razón por la que no es 2xCore es que esto es una VM y esas son vCPU en realidad, no núcleos reales.
Monitorearé la instancia por un tiempo y volveré para asignar la solución si ese es el caso, gracias @Stephen
El mensaje se relaciona con los recursos que asignas a Discourse, no con los recursos de la VM/host.
Obtén db_shared_buffers al 25% de tu memoria reservada y 2 workers de unicorn por CPU. Puede ser necesario un ajuste fino.
Obviamente, también necesitas administrar los recursos fuera de la VM si sientes que el grupo de recursos no es confiable. Casi todos los que ejecutan Discourse lo hacen en algún tipo de VPS.
No soy un experto en discourse, así que simplemente ejecuté el script que lo instala, ya que recuerdo que debería establecer esos parámetros según la memoria/cpu disponible.
He restaurado los workers a como estaban antes de algunas pruebas y volveré a revisarlo.
Para ser honesto, no tuvimos ningún problema con esas configuraciones, pero también podría no estar relacionado o solo estar parcialmente relacionado.
Tendré en cuenta tu sugerencia de 2 núcleos para los workers y el 25% de la memoria reservada para los buffers compartidos de la base de datos.
Cuando dices memoria reservada, ¿te refieres a la memoria reservada por el contenedor en ejecución? Porque parece ser siempre “tanta como el host tenga disponible” :ojos:
# db_shared_buffers: 128MB para 1GB, 256MB para 2GB, o 256MB * GB, máximo 4096MB
# UNICORN_WORKERS: 2 * GB para 2GB o menos, o 2 * CPU, máximo 8
‘máximo’ se puede tomar con una pizca de sal, especialmente las comunidades grandes verán beneficios más allá de esos números.
Así que sí, en tu caso debería haber especificado los máximos de 8 workers y 4096MB. Si reduces los workers y los shared buffers disponibles para Discourse, se agotará antes de que se consuman todos los recursos de la VM.
Esta publicación de @mpalmer sigue siendo una buena guía:
Me parece que se activa cuando las solicitudes están en cola durante demasiado tiempo; en otras palabras, las solicitudes llegan más rápido de lo que se atienden. Uno podría preguntarse por qué tantas solicitudes o por qué un servicio tan lento. A nivel de Discourse, hay parámetros ajustables que ya se discuten en este hilo y también, por ejemplo, en Error de carga extrema.
Desde entonces, todo parecía estar bien, pero desde hace un par de días el foro se siente “lento” a veces. Cuando digo lento, me refiero a que las solicitudes tardan en procesarse (enviar respuestas, editar, etc.) y justo ahora he notado el mismo mensaje de nuevo.
Fui a revisar el panel de Grafana que configuré y vi que el servidor está al límite en cuanto a uso de CPU.
Intenté reiniciar la aplicación, la carga sigue aumentando en la misma cantidad inmediatamente después del reinicio.
¿Hay alguna forma de ver qué tipo de proceso está utilizando la mayor cantidad de recursos? Intenté revisar el panel de Sidekiq, pero solo me muestra la lista de procesos en ejecución/en cola y el tiempo promedio de ejecución, algunos son lentos (tardan minutos), pero no veo nada en procesamiento ahora mismo ni fallando.
Estoy actualizando todo para eliminar cualquier posible problema que pudiera surgir debido a algún problema con beta5. Ahora en 3.1.0.beta6 - 6892324767.
Aún así, el uso de la CPU es anormalmente alto. Normalmente fluctúa alrededor del 60%.
Reinicié el VPS también, por si acaso estaba ocurriendo algo extraño (dudo que fuera así ya que comenzó de repente ayer después de 150 días de funcionamiento), pero no, el mismo comportamiento.
Es algún proceso unicornio consumiendo todos los recursos de la CPU. ¿Hay alguna forma de obtener más información sobre lo que están haciendo esos unicornios ahí atrás?
Para un vistazo rápido, por supuesto que oscila, pero este es el promedio de los trabajadores unicornio en funcionamiento, lo que me parece anormal cuando lleva en funcionamiento desde el día anterior:
Tu load average > 8 en una máquina de 8 vCPU significa que tu servidor está sobrecargado.
Entre 8 unicornios, muchos pids de PostgreSQL y todo lo demás en tu servidor, no puede procesar las solicitudes entrantes lo suficientemente rápido. Al menos tienes mucha memoria
Es algo inusual que Discourse se vea limitado por la CPU de unicornio de esa manera. La mayoría de las veces que he visto que esto sucede, ha sido debido a un plugin que se porta mal. ¿Puedes compartir tu app.yml?
También, por favor, comparte los resultados de MiniProfiler al cargar tanto tu página de inicio como la página de un tema.
He pedido al hosting que investigue si nos están robando tiempo de CPU otros VPS en nuestro host, ya que es muy extraño que haya sucedido tan repentinamente sin que nada realmente cambiara de nuestro lado.
Estoy esperando que el soporte técnico regrese con algunos resultados.
Gracias por las salidas. A modo de referencia, la primera línea de estadísticas de vmstat no es muy útil: las cinco líneas ofrecen la imagen necesaria.
Al final fue como supuse. Se desplegó otro VPS en el host y lo estaba agotando.
Nos trasladaron a otro host menos de 24 horas después de abrir el ticket.
Bravo a Contabo
Pediría a los moderadores que dejen estas últimas respuestas aquí, aunque no estén relacionadas con “discourse”, ya que pueden ayudar a otros a descubrir otras razones por las que su instancia podría tener problemas.
