Después de actualizar a la última versión de Discourse, ahora tenemos un problema extraño con ngix que genera el error 502.
Algunos usuarios obtienen el Error 502 al publicar, otros no. Algunos perfiles obtienen 502, otros no.
El uso de CPU es de alrededor del 10 al 25%, el uso de RAM es de aproximadamente el 20% también.
Intenté deshabilitar nuestros 5 complementos, mismo resultado.
¿A qué registros debo mirar para averiguar qué está produciendo estos errores 502?
Al mirar en I /var/log/nginx/error.log, parece que obtengo muchos de estos aleatoriamente, lo que supongo que produce el 502.
¿Simplemente se está agotando el tiempo de espera o qué?
2025/04/29 18:11:50 [error] 617#617: *419 upstream prematurely closed connection while reading response header from upstream, client: <IP>, server: _, request: "POST /posts HTTP/2.0", upstream: "http://127.0.0.1:3000/posts", host: "forum.domain.com", referrer: "https://forum.domain.com/"
¿Cuál era la versión anterior a la actualización?
Muy antiguo, como de un año o más. ¿Hay algún registro donde pueda ver de qué actualicé?
También estoy recibiendo algunos de estos
*2 connect() failed (111: Connection refused) while connecting to upstream,
...
upstream: "http://127.0.0.1:3000/message-bus/92fd28cbf742...
Parece aleatorio, de repente todo es rápido y puedo volver a publicar, y luego se vuelve lento y vuelven a aparecer los 502.
Mirando dentro del registro ‘postgres/current’
2025-04-29 18:48:24.709 UTC [1746] discourse@discourse LOG: duración: 606789.911 ms ejecución <unnamed>: SELECT COUNT(*) FROM "posts" WHERE "posts"."deleted_at" IS NULL
duración: 606789.911 ms
Tenemos muchas publicaciones, pocos usuarios… ¿por qué está utilizando 600k ms en esto?
¿Podrían ser problemas de indexación o algo similar lo que ralentiza las consultas?
Seleccioné la tabla de discourse en postgres y ejecuté un REINDEX DATABASE discourse; con la esperanza de que eso hiciera las cosas más rápidas.
Supongo que llevará mucho tiempo.
¿Seguiste el consejo de Actualización de PostgreSQL 15? También podrías hacer un VACUUM de la base de datos.
Yo no lo hice, sí tengo la carpeta postgres_data_old (aunque en un directorio diferente al de esa publicación).
Pero luego la publicación dice;
“Si estás ejecutando una configuración con un contenedor de datos dedicado”, lo que supongo significa que Postgres se está ejecutando en un contenedor de Docker dedicado?
El nuestro se ejecuta en la misma instancia que el foro. Así que no estoy seguro de cómo avanzar desde allí, ya que no parece haber una cláusula de “si no”.
¿El hecho de que exista la carpeta significa que la conversión fue correcta o qué?
Puedes verificar la versión de Postgres en /var/discourse/shared/standalone/postgres_data/PG_VERSION – Si realizaste una actualización desde la línea de comandos, es posible que haya realizado la actualización y no te hayas dado cuenta (pero tendrías que haber ejecutado la reconstrucción dos veces). Si actualizaste desde la interfaz web, probablemente deberías proceder a hacer una reconstrucción desde la línea de comandos si tu sistema operativo y Docker son versiones recientes.
La versión es 15.
Parece que las cosas han mejorado mucho después de ejecutar el comando vacuum.
Publicar funciona bien y parece ser rápido, pero cuando el administrador intenta hacer clic en los perfiles de usuario, acceder a sus perfiles, todavía da 502, parece que se agota el tiempo de espera.
¿Hay algo que pueda hacer para acelerar esa parte de la base de datos?
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.