Ah, veo, eso tendrá dificultades con esta consulta. Después de actualizar a la versión más reciente, ¿podrías extraer la consulta del mini_profiler, ejecutar un explain analyze sobre ella y compartirla con nosotros?
En Meta (RDS db.r6g.large 30GB) se ve así:
Intentaré ejecutar explain analyze nuevamente, pero no hemos podido lograr que esa consulta se complete correctamente.
Actualización: este commit no cambió nada. La base de datos sigue funcionando a más del 95% de forma constante después de la actualización y matando todas las consultas antiguas en ejecución. En la versión beta4 solía funcionar con una cadencia estable del 20-30% para este foro. Ya ejecutamos un auto-vacuum y una reindexación del esquema también.
¿Cómo desactivamos esta función? No parece correcto tener que aumentar la instancia de la base de datos para resolver esto; parece haber algo incorrecto en cómo se calcula esta consulta, dado que funcionaba perfectamente antes de esta actualización.
La consulta logró finalizar después de ~21 minutos
También cabe mencionar que estamos en PG 10.17, ya que parece que nuestros resultados difieren bastante.
Aplicamos un parche temporal (monkey-patch) para el problema reencaminando todas las rutas */private-messages-all/* a */private-messages/*. El resultado es que “todas las bandejas de entrada” tienen el mismo contenido que “Personal”, pero al menos ya no tenemos que lidiar con un uso del 100% de la CPU constantemente de esta manera.
Código del parche:
# name: discourse-private-messages-perf-hotfix
# version: 0.0.1
# authors:
# Prepend para sobrescribir rutas existentes
Discourse::Application.routes.prepend do
scope path: nil, constraints: { format: /(json|html|\*\/\*)/ } do
scope "/topics", username: RouteFormat.username do
# Reencaminar todas las rutas */private-messages-all/* a */private-messages/* en su lugar (mensajes personales)
# La primera es costosa, la segunda es económica, potencialmente ahorra un uso significativo de CPU de la base de datos
get "private-messages-all/:username" => "list#private_messages", as: "topics_private_messages_override", defaults: { format: :json }
get "private-messages-all-sent/:username" => "list#private_messages_sent", as: "topics_private_messages_sent_override", defaults: { format: :json }
get "private-messages-all-new/:username" => "list#private_messages_new", as: "topics_private_messages_new_override", defaults: { format: :json }
get "private-messages-all-unread/:username" => "list#private_messages_unread", as: "topics_private_messages_unread_override", defaults: { format: :json }
get "private-messages-all-archive/:username" => "list#private_messages_archive", as: "topics_private_messages_archive_override", defaults: { format: :json }
end
end
end
Uso de CPU de nuestra base de datos del foro después de implementar el parche anterior:
@tgxworld Querrás volver a revisar lo que están haciendo las rutas */private-messages-all/*; claramente hay algo mal en su implementación, no es lo suficientemente eficiente para bases de datos de foros grandes. O bien la implementación no está utilizando el índice de base de datos correcto o la generación de consultas está resultando en consultas extremadamente costosas (particularmente en PSQL 10, no estoy seguro sobre 12/13).
La implementación actual básicamente ha paralizado nuestro foro, aumentando el uso de CPU de ~15% a un 100% constante y causando un rendimiento lento en todas las demás funciones del foro. No veo ninguna razón por la cual las consultas de la bandeja de entrada Personal/grupo tomen <50 ms, mientras que las de “todas las bandejas de entrada” tardan más de 20 minutos en completarse.
Puedes usar el volcado de análisis que @forkythetoy publicó justo arriba para ver la ejecución de más de 20 minutos anterior.
@Falco Acabo de notar que has fusionado nuestro tema aquí, pero en realidad parece tratarse de un endpoint diferente. Este informe de error se refiere al endpoint private-message-topic-tracking-state, pero estamos hablando de */private-messages-all/*. Esto podría estar causando parte de la confusión aquí, mis disculpas por ello. (Inicialmente enlacé a este, lo que pudo haber iniciado el malentendido).
El private-message-topic-tracking-state es rápido en nuestro foro, por lo que este no es el problema para nosotros.
Para nosotros, este consulta consume entre 200 y 300 ms de tiempo de base de datos. Es un poco más de lo que uno podría esperar, pero aún así se encuentra dentro de los rangos normales, sí.
Sin embargo, estamos usando Postgres 13.
@Hooksmith Tengo una solución en proceso
@Hooksmith @forkythetoy ¿Podrán actualizar a PG 13? Esa es la versión mínima que requiere Discourse en este momento. Además, me resulta más difícil comparar los planes de consulta cuando las consultas no se ejecutan con la misma versión de PG.
Tuve que revertir esto porque el rendimiento de la nueva consulta difiere demasiado entre usuarios.
@blattersturm ¿Sigues experimentando que el rendimiento del seguimiento del estado de los temas es lento?
No estoy seguro, no he realizado ninguna actualización en los últimos días. ¿Hay algún commit que deba integrar para ver si hay alguna mejora?
No, nada ha cambiado, pero si puedes proporcionarme un EXPLAIN ANALYZE de la consulta, me sería de gran ayuda.
Ten en cuenta que, por ahora, revertimos la funcionalidad de todas las bandejas de entrada debido a preocupaciones de rendimiento.
Este tema se cerró automáticamente después de 14 días. Ya no se permiten nuevas respuestas.
