Mayor uso de CPU desde la actualización a 3.4.0.beta4-dev (58f75ed205)

He visto un aumento sustancial en el uso de la CPU desde la actualización de este fin de semana. El uso de la CPU de RUBY parece ser el principal impulsor. Otro usuario de Discourse hizo referencia a esto en este tema.

Como puede ver en los gráficos a continuación, el uso de CPU y la carga antes de la actualización fueron mucho menores que después de la actualización. La actualización ocurrió la noche del 31/1.

Aquí hay dos imágenes de TOP tomadas con 33 horas de diferencia:

En 33 horas, hay un uso significativo de CPU de Ruby. Según los datos de TOP, he visto un uso de CPU 2 veces mayor en las últimas 33 horas durante 22 días. En 33 horas, he visto 11 horas de tiempo de CPU. (648 minutos de tiempo de CPU en 5 PID)

Datos adicionales:

  • El tráfico ha disminuido en los últimos dos días en aproximadamente un 10%. (analíticas y panel)
  • Instalación estándar de Discourse en un solo contenedor (sin chat)
  • Las colas de Sidekiq son mínimas (1K a 2K por día)
  • No parece haber nada inusual en los registros de Discourse
  • Funciono en un servidor de DO con 8 GB de RAM y 2 vCPU AMD.

Este no es el caso en el que el servidor está crítico, pero los servidores que funcionan al 5% al 7% son mucho más felices que los que funcionan al 25%.

¿Qué información puedo proporcionar para ayudar a solucionar este problema?

gracias

3 Me gusta

Dejemos esto en soporte por un tiempo hasta que determinemos si hay un error.

¿Puedes entrar en el contenedor y ejecutar un htop desde el interior (tendrás que instalarlo) de esa manera podrás decir qué proceso específico está consumiendo grandes cantidades de CPU?

Puedes obtener un poco más de visibilidad utilizando una técnica como esta: Debugging 100% CPU usage in production Ruby on Rails systems

Lo más probable, sin embargo, es que sidekiq /sidekiq esté sobrecargado de alguna manera en tu instancia. (Me fijaría particularmente en el planificador)

Vistas de htop.

Aquí tienes un vídeo de 30 segundos:

Capturas de pantalla aleatorias:

Vista de árbol:

sidekiq:


Avísame si hay algo específico que necesites ver.

2 Me gusta

Sí, algo anda mal:

top -H -p PID_DEL_UNICORNIO

Sospecho que verás V8 DefaultWorker allí, creo que esto es una regresión en mini_racer… lo revertiré para ver si esto lo soluciona.

1 me gusta

OK, esto se ha revertido ahora,

Avísame si el commit restaura el rendimiento.

6 Me gusta

Sí, resolvió el problema de alta CPU. Mi carga de 1 y 5 minutos es aproximadamente 1/3 de los valores anteriores. Eso es con htop y netdata ahora ejecutándose en el sistema.

Video de HTOP

Gráfico de carga

Esperaría que el uso de CPU y la carga disminuyeran lentamente a medida que más consultas de base de datos se almacenan en caché en el sistema.

Tabla de carga:

tiempo Pre-reparación Post-reparación
1 min 0.4 a 0.6 0.06 a 0.1
5 min 0.39 a 0.5 0.15 a 0.18

La métrica de 15 minutos se ve afectada por una reconstrucción. Publicaré más estadísticas esta mañana.

Gracias por la reparación nocturna.

3 Me gusta

Lamento esto, la actualización de mini_racer ha sido una gran aventura. Esperamos superarla pronto.

3 Me gusta

Gracias por la rápida respuesta para investigar.

Estoy seguro de que tenías otras cosas planeadas para el día además de una reversión.

Como nuevo usuario de Discourse, 2 semanas desde la migración, el producto ha sido genial para trabajar.

2 Me gusta

Historia similar aquí también.

[Editar: parece que ya se ha solucionado después de actualizar a la última rama]

Aquí hay una revisión de rendimiento 18 horas después de la reconstrucción. La tabla de carga lo dice todo.

Tabla de Carga:

tiempo Pre-reparación Post-reparación
1 min 0.4 a 0.6 0.03 a 0.05
5 min 0.39 a 0.5 0.09
15 min 0.68 0.12

Leyenda:

  • Flecha roja - reconstruyó la aplicación
  • Flecha morada - desactivó netdata

Nota, para cerrar el ciclo, el error que lo causaba era este:

Actualicé la gema. Una ventaja inmediata es que parece que esta versión de v8 utiliza un poco menos de memoria, lo cual es bueno.

6 Me gusta

Lo instalé la última versión anoche con la corrección. El uso de la CPU ha vuelto a los niveles históricos.

Gracias por todo el gran trabajo.

1 me gusta

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.