Hola a todos,
Hemos actualizado nuestro servidor CentOS 7 de la versión 2.2.2 a la 2.7.0.beta4 y, desde entonces, estamos experimentando latencia en la carga de las páginas. Esto ocurre especialmente en las páginas que involucran bases de datos o contenido de imágenes, hasta el punto de que se ha vuelto inutilizable.
Agradeceríamos mucho cualquier orientación al respecto.
Un montón de cosas han ocurrido en los últimos años. Hubo un cambio en los datos que requiere procesar todas las imágenes. Sospecho que tu servidor está saturado realizando ese trabajo. Puedes revisar /sidekiq para ver la cola.
¿Qué tamaño tiene tu base de datos? ¿Cuántas imágenes hay? ¿Qué muestra sidekiq? ¿Estás usando SSD, verdad?
Es un servidor basado en una máquina virtual, así que no estoy seguro de si es SSD o no. No veo Sidekiq accesible, ya que esta implementación no fue realizada por mí, por lo que no sé cómo acceder a él.
¿Sabes cómo se instaló? Parece que no es una instalación estándar (de lo contrario, /sidekiq estaría disponible para ti si fueras administrador).
Tu mejor opción es investigar por qué el rendimiento ha disminuido. A lo largo de los años se han añadido muchas tareas en segundo plano (optimización de imágenes, rebaking, etc.) que probablemente se están ejecutando ahora y consumiendo los recursos de tu servidor. Una vez que se completen, el rendimiento debería mejorar.
Acceder a /sidekiq (usando una cuenta de administrador) para descubrir qué tareas se están ejecutando es un excelente primer paso.
Bien, logré acceder a Sidekiq. ¿Me podrían ayudar a entender esto y sugerir alguna optimización? Estoy en un aprieto debido a estos problemas de rendimiento.
El comportamiento que observo en el servidor es que sigue mostrando esta cola vacía incluso cuando intento abrir una publicación para verla listada, pero el portal de Sidekiq también se bloquea mientras se carga la publicación y solo se actualiza una vez que la publicación está completamente cargada.
Además, una vez más, cuando se carga, muestra una cola vacía. Cualquier ayuda o sugerencia sería muy apreciada.
Si la cola está vacía, entonces no tienes el problema de que se estén ejecutando muchas tareas en segundo plano. Por lo tanto, se trata de otra cosa.
¿Tienes algún plugin? ¿Tienes componentes del tema que estén realizando muchas llamadas a la API?
Hice algunas otras preguntas arriba.
¿Qué tamaño tiene tu base de datos?
¿Cuántas imágenes hay?
¿Tienes componentes del tema que estén realizando muchas llamadas a la API?
¿Podrías indicarme cómo puedo obtener esa información en una configuración basada en Docker? Sé que la última copia de seguridad es de 135 MB.
En cuanto a los complementos, sí, tenemos los siguientes listados:
- git clone https://github.com/discourse/docker_manager.git
- git clone https://github.com/jonmbake/discourse-ldap-auth.git
- git clone https://github.com/discourse/discourse-math
- git clone https://github.com/discourse/discourse-chat-integration.git
- git clone https://github.com/discourse/discourse-voting.git
- git clone https://github.com/unfoldingWord-dev/discourse-mermaid.git
- git clone https://github.com/discourse/discourse-solved.git
- git clone https://github.com/discourse/discourse-assign.git
- git clone https://github.com/discourse/discourse-knowledge-explorer.git
- git clone https://github.com/discourse/discourse-cakeday.git
Recomiendo eliminar el plugin de Mermaid.
¿Cuántas publicaciones y usuarios tienes? ¿Qué tráfico recibes?
¿Cuánta memoria RAM tienes?
Parece que te iría bien con un droplet de 2 GB de DigitalOcean; podrías crear uno y ver cómo funciona.
¿Quizás haya algún otro problema con tu servidor? ¿Está actualizado? ¿Se ha reiniciado recientemente?
Ok, lo eliminaré.
Tenemos aproximadamente 4k publicaciones y alrededor de 350 usuarios.
El número promedio de usuarios conectados simultáneamente no es muy alto, quizás de 5 a 10 como máximo en promedio.
Este servidor se levantó recientemente y comparte 8 GB de RAM con 10 GB de espacio de intercambio. Además, solo ha estado activo durante 13 días hasta ahora. Sin embargo, los problemas de rendimiento ocurren independientemente del reinicio y del tiempo de actividad.
Definitivamente hay algo incorrecto con tu instalación; deberías obtener un rendimiento mucho mejor con este hardware.
Intenta que PostgreSQL realice un VACUUM explícito. Si estás utilizando la instalación del contenedor todo en uno:
# docker exec -it -u postgres app psql discourse
psql (13.1 (Debian 13.1-1.pgdg100+1))
Escribe "help" para obtener ayuda.
discourse=# VACUUM ANALYZE;
VACUUM
¿Cuántos workers de unicornio tienes configurados en tu archivo app.yml?
Puedes pedirle a Discourse que incluya encabezados de rendimiento adicionales en las respuestas añadiendo lo siguiente en tu sección env:
DISCOURSE_ENABLE_PERFORMANCE_HTTP_HEADERS: true
Mientras estás en ello, puedes activar miniprofiler siguiendo este post.
Eso debería ser suficiente.
No recuerdo si se sugirió que volvieras a ejecutar discourse-setup para ajustar el uso de memoria de Discourse, o si esos valores predeterminados son razonables considerando lo demás que está usando el servidor.
Si no reindexaste la base de datos después de la actualización a PG13, podrías consultar Actualización a PostgreSQL 13 para obtener más información al respecto.
¡Oh sí, la falta de estadísticas de tabla (VACUUM ANALYZE) es el culpable más probable aquí.
VACUUM FULL VERBOSE;
REINDEX DATABASE discourse;
VACUUM VERBOSE ANALYZE;
Así que ejecuté estos comandos y también configuré el encabezado en el entorno, pero no veo mucha diferencia en el tiempo de carga de la página.
Estoy ejecutando 8 unicorns.
¿Ejecutaste esos comandos en PostgreSQL, verdad?
Sí, ejecuté docker exec -it -u postgres app psql discourse antes de ejecutar los comandos anteriores.
Bueno, eso es muy extraño. Nadie más ha tenido problemas similares. Parece que tienes suficiente hardware. Mi única suposición es algún problema con un proxy inverso (supongo que tienes otras cosas en la máquina, ¿verdad?).
sí, otro servicio basado en Docker.
Pero nada realmente intensivo en cuanto a rendimiento, ya que eso se habría reflejado en las métricas de rendimiento de la máquina.
